anyhow Result support

[fdietze]

Hi, I'm wondering if it's possible to support the anyhow::Result type without introducing an Error-wrapper, as implemented in this example:

axum/examples/anyhow-error-response/src/main.rs

Line 37 in 994492d

struct AppError(anyhow::Error);

struct AppError(anyhow::Error);

// Tell axum how to convert `AppError` into a response.
impl IntoResponse for AppError {
    fn into_response(self) -> Response {
        (
            StatusCode::INTERNAL_SERVER_ERROR,
            format!("Something went wrong: {}", self.0),
        )
            .into_response()
    }
}

As far as I understand, we need it, because Rust forbids to implement the trait IntoRespone for anyhow::Error directly, because they come from different crates. But now my handlers have to return Result<..., AppError instead of the preferred anyhow::Result<...>.

Is there a way around this limitation? Or would it be feasible to implement direct anyhow support into axum behind a feature flag?

Thank you!

[davidpdrsn]

Technically it is possible but I think it would be a footgun and leads to many questions. How should it be turned into a response? As text, json, xml, yaml? What should the formatting be like? anyhow::Errors are also likely to contain private details about the application that you don't want to expose to clients.

Therefore we recommend you make a wrapper like shown here https://github.com/tokio-rs/axum/blob/main/examples/anyhow-error-response/src/main.rs

[fdietze]

Thank you. True, if that trait would be implemented in axum, I don't have the control anymore how to turn anyhow::Error into a Response. Is there a way, the user can provide the mapping for the trait implementation somehow? That way, the user wouldn't have to give up any control.

[davidpdrsn]

Nope. You have to make a wrapper and implement IntoResponse for it.

[edezhic]

How about responding with 500 and if #[cfg(debug_assertions)] => Display/Debug in the body, while also logging/tracing?

Current anyhow example is pretty verbose and it seems like an easy opportunity to improve usability

[edezhic]

@davidpdrsn probably a misunderstanding here
I mean to respond with 500 (or another code, but 500 seems semantically correct) and log/trace in any case
But also add Debug/Display or some other Error-specific stuff into the body under debug assertions

[davidpdrsn]

Hm I’m not sure. I still don’t feel the few lines of boilerplate is worth the potential confusing it brings.

[edezhic]

@davidpdrsn what kind of confusion? Seems reasonable for an HTTP router to return 500 if encountered an unspecified error
If someone needs specific error handling it would still be possible to create custom error types/wrappers
But pretty much all web frameworks I've encountered behave that way on unexpected errors: return 500 (with debug info in debug mode)
Ideally it shouldn't even depend on anyhow but work for any type that implements std Error in my view

[davidpdrsn]

But pretty much all web frameworks I've encountered behave that way on unexpected errors: return 500 (with debug info in debug mode)

You’re making it sound harder than it actually is.

The potential confusing is not knowing what returning anyhow::Error actually does. By requiring people to define their own wrapper that’s not an issue.

[edezhic]

@davidpdrsn I didn't mean to make it sound hard, only that it will improve devex and won't be confusing