An Error that Users can create to give to hyper

[seanmonstar]

Part of the Error reform.

Motivation

Unlike the hyper::Error, which is meant to describe an error that occurred inside hyper and that information given the user, there a few instances where the user must tell hyper that an error has happened outside, and to stop it's scheduled action.

• In the Client (see also A better Client Error experience #1130):
  • The user can create a Request<B>, with a custom Stream. They may need to tell hyper that the stream cannot be completed.
• In the Server (see also A better Server Error experience #1128):
  • The user can create a Response<B>, with the same characterics and needs as the Client's Request<B>.
  • The user can provide a Service (and NewService), which returns Future<Item=Response<B>>, where that Future might also fail in creating a Response. In most cases, a robust server will want to send a response anyways, with a 4XX or 5XX status code, but there could exist instances where the user can't even (or doesn't want to) create those responses.

While hyper was using tokio-proto, there was a limitation on what error types could be used (only a single error type was allowed), but now that hyper has moved off, we can solve this (even now, before 0.12, I believe).

Design

(updated from #1431 (comment))

Allow E: Into<Box<std::error::Error>> in any place a user could return an error to hyper. That means:

• In the server, Service::Error: Into<Box<std::error::Error>>.
• The body streams (Entity) a user can provide should be changed to just type Error: Into<Box<std::error::Error>>;
• The Connect trait should update to type Error: Into<Box<std::error::Error>>, and the bounds C::Error: io::Error on client should be removed.

[dekellum]

Assuming that by users you mean developers/code using the Hyper crate, perhaps a better name for this is (error::)Application? "User" might otherwise get confused, for example, with some authorization mechanism.

[seanmonstar]

Instead of some hyper::error::User, this could just be Box<std::error::Error> instead. This punts allowing the error type to indicate an HTTP2 error code to reset with, but it's probably otherwise much clearer. Basically, all things in hyper that would allow a user to signal an error occurred could just be E: Into<Box<std::error::Error>, which is the same bounds like for std::io::Error::new(kind, my_error).

Some benefits here:

• Users can return their own error type, making it easier to plug their app in, and logs can show exactly the message that they wanted.
• This still works with hyper::Error, so proxying one hyper::Body as the body of another message works fine. With specialization, we can remove the box internally, but not a big problem either way.
• We still benefit from not having weird hyper::Error::from(io_err).