Provide introspection on hyper::Error

[jonhoo]

I have an application in which I want to try to set up a server on a specific port, but if that port is taken (i.e., an AddrInUse error is raised), it should fall back to any port (i.e., port 0). Unfortunately, since hyper's error type is now opaque (as of 5d3c472), I can no longer easily see if that was the cause of an error raised by Server::try_bind.

While I could construct a TcpListener myself and then pass that listener's Incoming to Server::builder, that's an unfortunate amount of extra boilerplate. Perhaps it would make sense to expose an as_io_error(&self) -> Option<&io::Error> on hyper::Error?

[seanmonstar]

I saw mention of this in IRC, it seems you can't downcast the cause because Error::cause() doesn't return a Error + 'static, right?

What if hyper::Error were to get a cause_static (sorry, naming is hard) method, kind of like std::io::Error::get_ref, to allow downcasting?

[jonhoo]

That'd be nice, but is there a particular reason you don't want to expose the io::Error through an explicit as_io_error method? As someone pointed out on IRC when I asked about it, cause() isn't really intended to be used as a way to figure out if a particular error occurred. Part of this is because causes form a chain, and you don't technically know how deep you have to go. And more importantly, the error nesting could change between versions.

[seanmonstar]

I'm not especially against some form of as_io_error, I was just thinking that people may wish to access the errors they created themselves, like from a Payload or Service, and suggested something that might solve all cases.

[jonhoo]

Oh, yeah, I think having both is probably a good idea! I think my concern about cause nesting would make it pretty difficult to extract user errors from behind a hyper::Error nonetheless, but at least it would be possible!