Better documentation/discussion for error handling

[prabirshrestha]

Would it be possible to add error handling example in https://trillium.rs/ ?

Doc are great by the way for a new project.

[jbr]

Doc are great by the way for a new project.

Thanks!

The absence of error handling is not entirely a mistake, but I should address it directly in the documentation. Currently, the error handling story is the least-developed aspect of Trillium, but we are limited by what the language can express at the moment. In the future, we'll be able to have a

trillium_smol::run(ErrorHandler::new(async move |conn: &Conn| -> Result<(), MyError> {
    Ok(())
}));

… but until the language develops the capability to express the bounds for for<'a> Fn(&'a Conn) -> impl Future<Output=…> + 'a, it's a matter of picking the least-bad workaround, and that's going to end up being outside of trillium core.

There are two macros available to make this easier: trillium::conn_try! and trillium::conn_unwrap!, but I expect there'll be further improvements.

Regardless of how it turns out, error handling is going to end up looking very different from tide. In particular, I think there's a distinction between "returning a non-200 response" and a rust Err, and that the code to translate between them should live entirely in the application. I think most applications will want to have a single thiserror-style enum Error that also implements Handler.

[prabirshrestha]

I was actually looking into some sort of error handling sort of middleware (handler) that auto converts errors to json/html bad requests or 500 or thiserror to some json represntation.

trillium_smol::run(
    Router::new()
        .get("/users", {conn-> Err('blah') ))
        .get("/posts", posts_api),
    ErrorHandler::new(async move |conn: &Conn| -> {
        conn.with_status(500).with_body(json!(conn.err()))
    });
);

[jbr]

Yeah, that's not possible yet in async rust

[jbr]

I'm going to convert this to a discussion because I believe this will be a long-running topic of discussion, but will re-create an issue to represent the short term need for better documentation