The problem with Go’s default HTTP handlers

Re:The problem with Go’s default HTTP handlers by masklinn on Tuesday August 09, 2022 @12:12PM (#32399893)

I’ve not yet gotten to use it, but I understand Axum also implements IntoResponse for Result<A: IntoResponse, B: IntoResponse>, which is very convenient for the sort of error code of the above.

It’s one of my biggest annoyance with Warp: it only implements Reply for `Result<T, http::error::Error>`, so if you have a faillible handler with more complicated error types (e.g. with a json body, or even a 200 response for RPC handlers) you’re in the awkward position of having to join the paths back (usually by converting everything to a Response by hand), which makes mistakes easier.

[ Parent | on HN ]

Re:The problem with Go’s default HTTP handlers by zaarn on Wednesday August 10, 2022 @07:00AM (#32410070)

Correct, I spent about half an hour implementing IntoResponse for my own project's error type, but now I can just use normal error handling and I get presented with an error page on any issues. It's quite magic (not really, very streamlined).

[ Parent | on HN ]