Integrating with actix-web

[eyre-rs]

Integrating with actix-web

[mickdekkers]

For those looking for a solution to use in the meantime, this pattern combining eyre with thiserror works quite well:

#[derive(thiserror::Error, Debug)]
pub enum RouteNameHereError {
    #[error("{0}")]
    ValidationError(String),
    #[error(transparent)]
    UnexpectedError(#[from] eyre::Error),
}

impl ResponseError for RouteNameHereError {
    fn status_code(&self) -> StatusCode {
        match self {
            RouteNameHereError::ValidationError(_) => StatusCode::BAD_REQUEST,
            RouteNameHereError::UnexpectedError(_) => StatusCode::INTERNAL_SERVER_ERROR,
        }
    }
}

#[get("/route-name-here")]
async fn route_name_here() -> Result<(), RouteNameHereError> {
    Err(eyre!("Something went wrong!"))
}

Source: https://www.lpalmieri.com/posts/error-handling-rust/#using-anyhow-as-opaque-error-type

[yaahc]

Hi, great library, I'm enjoying it.

Thank you and I'm glad. Hearing that puts a smile on my face ^_^

Any tips on how I could use eyre::Result in this scenario? And food for thought, here is how I hacked some existing code to use the stdlib Result in actix-web:

The standard approach is to use a feature flag to implement the given trait in one crate or the other. It looks like someone already requested¹ support for anyhow in actix-web and got denied, so having the trait implementation live in actix-web is likely out of the question, tho I suppose it would be worth double checking if the maintainer involved in that decision is still the lead maintainer or not. Edit: it seems that they are not infact involved anymore

Looking at ResponseError it looks like it's meant to solve the same problems I'm trying to solve with generic member access, though it does so statically rather than dynamically which has a different set of tradeoffs. Either way though it wouldn't work with eyre because of limitations in rust's trait system that currently prevent eyre from implementing Error, even if we could convince actix-web to switch back to the standard library Error trait rather than requiring their own.

In the end it looks like this is a rather large mess. I can understand why actix decided to define their own Error trait but doing so makes them fundamentally incompatible with the rest of the ecosystem's error handling, so I can't immediately think of any good solutions for using eyre in that environment. It might be that we can convince them to switch back to the Error trait when generic member access is stabilized, and I would certainly love to get their feedback on that feature to know whether or not it would be an acceptable solution for their usecases, but that's only one of the problems to solve here. I'm sorry I don't have better news >_<.

Footnotes

1. https://github.com/actix/actix-web/pull/1241 ↩

[yaahc]

It actually looks like the maintainer who closed that PR isn't the one maintaining actix-web anymore, so I think it's almost certainly worth pinging @robjtede here to get their opinion and to see if we could start working on migrating actix-web back to the standard library error trait.