Add response::ErrorResponse and response::Result

[npmccallum]

This type makes for efficient use of the ? operator when in a function
with multiple return error types that all implement IntoResponse.

Signed-off-by: Nathaniel McCallum nathaniel@profian.com

[npmccallum]

This PR is similar to #911 but is simpler. Note that to achieve this simplicity, Error must not implement IntoResponse. Otherwise, we collide with other blanket implementations.

[davidpdrsn]

Can this be defined outside of axum-core, perhaps axum-extra? I would like to avoid expanding its API unless necessary.

[jplatte]

I'm pretty sure this can't be defined elsewhere, that IntoResponse impl would violate the orphan rule.

[jplatte]

I really like this, but if we decide to have it, it would be good do have more docs before merging.

I also wonder whether this should have a more specific name and/or whether there should be a Result alias for it.

[npmccallum]

@jplatte I like the idea of a Result alias. I don't have strong opinions about the name. However, having Error with an associated Result alias is a pretty common Rust idiom.

Can you tell me what additional docs you're looking for?

[jplatte]

Before putting more effort into this, I think it makes sense to hear what David thinks again.

In terms of docs, I am thinking of

• mentioning this type / the Result alias if it's added in the main crate's docs
• adding an example to the type's docs

[npmccallum]

@jplatte I already added an example in the Result alias docs. I'll wait for @davidpdrsn before making any new pushes.

[davidpdrsn]

I think it's looking good but I wanna play around with it a bit first to see. I'll do that during the weekend and let you know 😊

[npmccallum]

@davidpdrsn Any update?

[davidpdrsn]

Not yet sorry. I'll let you know.

[davidpdrsn]

I personally prefer having a single error enum made with thiserror and a manual implementation of IntoResponse but for more adhoc stuff this might be nice.

I think the name Error is too broad though, it also conflicts with axum::Error. What about ErrorResponse or ResponseForError?

[jplatte]

I like the suggestions of ErrorResponse, in which case maybe the result alias should also have a more unique name (ResultResponse)?

[npmccallum]

@jplatte @davidpdrsn I'll leave the decision up to you guys. However, ErrorResponse and ResultResponse seem very non-Rust idiomatic to me. The Rust idiom is to name types Error and Result within their own module. For example: std::io::Error and std::io::Result.

[jplatte]

The thing is that ErrorResponse isn't really an error in the traditional sense (it doesn't implement std::error::Error). The fact that ResultResponse is a type alias for Result<_, ErrorResponse> is basically an implementation detail necessary to make ? work currently – we could change this in a breaking release once the try-related traits are stable and can be implemented for thirdparty types.

[davidpdrsn]

I'm updating this branch now in case you didn't notice. Hopefully I haven't overwritten anything you've done locally.

You're right about std having multiple error types but I see that as kind of a special case, and honestly not very user friendly. I have heard from several users who have been confused about types with the same names, even though they were in different modules. Json for example used to two types. One that was an extractor and one that was a response. That was changed in axum 0.2 I believe.

The error types in std also implement std::error::Error which makes them more error-like I suppose. This error type wouldn't implement that trait.

[npmccallum]

My intuition is that less than half of all types used as an error in Result within the Rust ecosystem actually implement std::error::Error (there are a variety of reasons for this, many of which caused the creation of crates like anyhow and thiserror). So I don't see that as a reason to break the idiom here.

And while I agree there is a minor paper cut having two types with the same name in two different modules, I think the greater sin is diverging from ecosystem-wide convention. Anyone who learns Rust will hit the Result naming convention pretty immediately. Diverging from that pattern therefore feels weird to me.

[davidpdrsn]

I think keeping the Result name is probably fine, thats quite common. But I think we should stick with ErrorResponse.

[jplatte]

I don't care too much either way.

[npmccallum]

I'm good with the above compromise.

[davidpdrsn]

Sweet! I'm fixing up the PR now 😊

[npmccallum]

I am too. :)

[npmccallum]

@davidpdrsn I'll let you fix the PR since you know how you want it.

[npmccallum]

I have rebased and made the discussed changes.

[npmccallum]

@davidpdrsn I may have accidentally done a force push seconds after your push.

[davidpdrsn]

Why 😭 I had made a bunch of nitpicky docs changes that I might just force push on top of yours then.

[npmccallum]

@davidpdrsn I'm so sorry! Do you still have the commit locally?

[davidpdrsn]

Yep! I'll look at it tomorrow 😊

[davidpdrsn]

[jplatte]

Small nitpick about the changelogs, otherwise looks great!

[davidpdrsn]

@npmccallum Thanks for working on this!