A better Client Error experience

[seanmonstar]

As discussed in #1128, there is good reason to consider having 2 different error types, and they would be useful for the Client as well. The hyper::Error is the correct error type for the Client to return from its Future, as well as from the response's body stream.

However, It does not makes sense for the request body stream to require sending a hyper::Error if generating the body failed. In that case, nothing in hyper failed, and the only relevant thing to hyper is that the stream cannot be completed. So the error type sent should be some sort of Disconnect or Abort or whatever, since an error on the body stream means the only thing hyper can reasonably do is to give up on the connection.

As in the server issue, the From<std::io::Error> and From<hyper::Error> implementations would be useful to allow easily sending streams from other sources, but it would be clear that the actual error type means "kill it dead."

---

New proposal: #1431

[sanmai-NL]

Every function/method can have its own error type. More general abstractions may seem reasonable now, but have such a large API surface that revising error handling will break code all over the place. The abstraction of Errors as being server or client-related, or problematic vs. not really problematic (your request body streaming comment) is not needed in my view.

[seanmonstar]

@sanmai-NL I don't quite understand which way you lean. You say each method can have its own type, but that it's not needed in hyper.

[sfackler]

One thing I'd like is to differentiate IO errors based on where they came from. I care about connect errors in particular, since you can retry the request on a different host if you can't connect to one of them, even if the request isn't idempotent or you have a body you can't reset.

[seanmonstar]

I made a comment in #1131 about having an internal Connect variant (and related ways to inspect for that).

[sanmai-NL]

@seanmonstar, regarding #1130 (comment):
I’m saying the current abstract distinction between Server and Client in the API is not ‘needed’ w.r.t. to error handling. With ‘needed’, I meant to say that it works better to have an error type for every fallible function. That’s simple and always works.

#[derive(Copy, Clone, Debug)]
pub enum MyFnError {
    FailurePathOne { cause: OtherFnError },
}

impl Display for MyFnError {
    fn fmt(&self, f: &mut Formatter) -> fmt::Result {
        fmt::Display::fmt(match *self {
            FailurePathOne::OtherFnError { .. } => "Failed, ... . ",
        }, f)
    }
}

impl Error for MyFnError {
    fn description(&self) -> &'static str { "" }

    fn cause(&self) -> Option<&Error> {
        match *self {
            MyFnError::FailurePathOne { ref cause, .. } => Some(cause),
        }
    }
}

pub type MyFnResult = Result<(), MyFnError>;

[dekellum]

Edit: What follows was ill-informed on my part, but gives an example of how a new and foolish user might make the mistake of trying to instantiate a hyper::Error. See comment below.

Hi, I'm not sure this is still open for feedback or where its progressing, but given my evolving use case, I'm surprised by this opening comment:

The hyper::Error is the correct error type for the Client to return from its Future, as well as from the response's body stream.

As of hyper 0.11 this is of course a requirement, but I'm finding that awkward. I'm implementing a client that needs to be resilient to retrieving large responses up to ~1GiB in size and processing these with more than one pass. After retrieving a threshold size the client will switch from in-memory to buffering the response on disk. In addition the client may wish to terminate response streaming early if the initial Content-Length header, or the actually received chunked response, is too large (for example, given available disk space.) I don't want to panic in these cases, but I do want the body stream to terminate and hyper to close the connection (which won't be completely read). These kinds of errors are entirely in the domain of my application, but as it stands, my best route is along the lines of:

if length_to_read > self.max_payload() {
    Err(IoError::new(
        ErrorKind::Other,
        format!("[APP] response body too large: {}+", length_to_read)
    ).into()) // -> hyper::Error
} //...

Also my disk based implementation can io::Error, but as it stands its going to be difficult without hacks like the above to reliably distinguish between I/O errors originating from the HTTP sockets and my disk impl. I/O errors. But distinguishing these is important to determine which should be retried vs. resulting in a fatal application error.

My personal ideal would be the ability to use the failure crate's Error type inside of FutureResponse::and_then and Body::for_each, or some kind of trait object. If that is too high level or costly, then how about an AppError(u32) variant in the hyper::Error enum or a reserved application error range in a numeric hyper error?

[sfackler]

@dekellum Just because the Client's future returns a hyper::Error doesn't mean your future that works off of that has to return a hyper::Error. client.get("http://google.com").map_err(|hyper_error| MyErrorType::from(hyper_error)).

[dekellum]

Yes, thanks, but like with my above code example originating in hyper::Body::for_each(Fn) I would end up hoping(!) I'm the only one using ErrorKind::Other or prefix matching on "[APP]" in order to convert the sub-set of all possible errors that are my own applications errors. Its a hack at best.

[sfackler]

Like this?

response.body().map_err(|hyper_error| MyErrorType::from(hyper_error)).for_each(Fn)

[dekellum]

No, unfortunately the logic that decides upon and produces the error needs to be in the Fn itself, which is defined by hyper to return a Future with type Error=hyper::Error.

[sfackler]

I don't understand. for_each passes the closure a Chunk, not a Result. It never sees the error that is transformed by the map_err.