Using HandleError::new() with extractors? #1279

cameronelliott · 2022-08-18T22:33:17Z

cameronelliott
Aug 18, 2022

I think Axum is awesome!

The new documentation on error handling is really good too: error_handling

One thing I cannot figure out, is whether HandleError::new() should work
with extractors or not.

    let app = Router::new()
        .route("/foo", post_service(HandleError::new(service, handle_anyhow_error)))
...

async fn handle(request: Request<Body>) -> Result<Response<Body>, anyhow::Error> {
    let b = Body::from("hello");
    Ok::<_, anyhow::Error>(Response::new(b))
}

Should I be able to add extractors to handle()?. I have been unable to get this to work.
If this is possible, it would be great to see it in the docs, or as a comment here.
(For newer Rust programmers myself)

Thanks

Answered by davidpdrsn

Aug 19, 2022

Yep that is possible. See https://docs.rs/axum/latest/axum/error_handling/index.html#running-extractors-for-error-handling

can you post more of your code including the error you get?

View full answer

davidpdrsn · 2022-08-19T05:51:16Z

davidpdrsn
Aug 19, 2022
Collaborator

Yep that is possible. See https://docs.rs/axum/latest/axum/error_handling/index.html#running-extractors-for-error-handling

can you post more of your code including the error you get?

5 replies

cameronelliott Aug 19, 2022
Author

Thanks for the prompt response. 💯

I saw and studied that part of the docs also, but it just seems to demonstrate how to
do an extractor with the handler for a layer/middleware.

I want to use an extractor not with the middleware error-handler, but
either before or inside the thing_that_might_fail().

There is a minimal/not-working example here:
https://github.com/cameronelliott/axum-errors-extractor
In the example, I want to use extractors with thing_that_might_fail().

I understand how to pass Request<Body> into thing_that_might_fail(), and I could
probably do everything the extractors do by-hand, but who wants to pull apart the Request<Body> by hand?

I'm sorry if I am missing something obvious.
Thank you for your help, I've been trying to get this going all day.

davidpdrsn Aug 19, 2022
Collaborator

Oh so your question has nothing to do with HandleError then.

thing_that_might_fail is a regular rust function that takes a Path and a Request. So you cannot just pass a Request to that. You can use Handler::into_service to convert thing_that_might_fail (which implements Handler) into a tower::Service and then call it.

However I'm curious. Why are you even trying to do this in the first place? Why not use the regular Handler, get, post, etc. machinery that axum provides?

cameronelliott Aug 19, 2022
Author

David thank you.
Yes, good question, why don't I just use a handler?
Let's say I have this code:
let app = Router::new().route("/foo", get(handler));

Well, I have written a long function handler which
has maybe more than a dozen or more places where I want to use ...await?;
along with maybe Ok("my body here") at the end when there are no errors.

That's it, I just have a very long Handler function in which I need a lot of ...await?;

Although as I am thinking about it, maybe I just need a regular Handler wrapping/calling an inner function
that returns a Result<String, anyhow::Error>, and then the handler converts it to a body.
Maybe that's the best solution?

What I was hoping to achieve was:

let app = Router::new().route("/foo", get(handler_xxx));

...

async handler_xxx(..extractors) -> Result<String,anyhow::Error> {
...
}

But now it seems that's not possible?
(Again, I understand I can just implement this as two functions:)

let app = Router::new().route("/foo", get(handler));

...
async handler(...extractors...) -> Result<String, StatusCode>  {
 let a = handler_inner(...);
 if Err(a) {
   // return status code
 }

async handler_xxx(..extractors) -> Result<String,anyhow::Error> {
   foo().await?;
   ...
}

Thanks for any more thoughts you can share.
Cameron

davidpdrsn Aug 19, 2022
Collaborator

I recommend creating a wrapper around anyhow::Error that implements IntoResponse and From<anyhow::Error>:

use axum::{http::StatusCode, response::IntoResponse, routing::get, Router};
use std::net::SocketAddr;

#[tokio::main]
async fn main() {
    let app = Router::new().route("/", get(handler));

    let addr = SocketAddr::from(([127, 0, 0, 1], 3000));
    axum::Server::bind(&addr)
        .serve(app.into_make_service())
        .await
        .unwrap();
}

async fn handler() -> Result<(), AppError> {
    try_something().await?;

    Ok(())
}

async fn try_something() -> Result<(), anyhow::Error> {
    Ok(())
}

struct AppError(anyhow::Error);

impl From<anyhow::Error> for AppError {
    fn from(err: anyhow::Error) -> Self {
        AppError(err)
    }
}

impl IntoResponse for AppError {
    fn into_response(self) -> axum::response::Response {
        // how do you figure out what actually went wrong?! All the type information is erased in
        // `anyhow::Error`
        StatusCode::INTERNAL_SERVER_ERROR.into_response()
    }
}

But actually I don't recommend using anyhow::Error at all for web apps. The issue being that all type information is lost, so how do you convert the anyhow::Error into an appropriate response? I'd recommend thiserror instead so you actually know what went wrong and can create appropriate responses.

cameronelliott Aug 19, 2022
Author

Thank you so much @davidpdrsn I will try that tomorrow (past my bedtime). Very much appreciated. Cameron 💯

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Using HandleError::new() with extractors? #1279

{{title}}

Replies: 1 comment 5 replies

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

Select a reply

Using HandleError::new() with extractors? #1279

cameronelliott Aug 18, 2022

Replies: 1 comment · 5 replies

davidpdrsn Aug 19, 2022 Collaborator

cameronelliott Aug 19, 2022 Author

davidpdrsn Aug 19, 2022 Collaborator

cameronelliott Aug 19, 2022 Author

davidpdrsn Aug 19, 2022 Collaborator

cameronelliott Aug 19, 2022 Author

cameronelliott
Aug 18, 2022

Replies: 1 comment 5 replies

davidpdrsn
Aug 19, 2022
Collaborator

cameronelliott Aug 19, 2022
Author

davidpdrsn Aug 19, 2022
Collaborator

cameronelliott Aug 19, 2022
Author

davidpdrsn Aug 19, 2022
Collaborator

cameronelliott Aug 19, 2022
Author