Reconsider use of failure crate in rust projects

[brson]

This comment from @BurntSushi came to my attention lately where he argues against using error libraries in teaching material, and I've heard other skepticism about the wisdom of using failure in production, as it is not completely endorsed by the Rust team as a solution for error handling.

My opinion is different - I think that writing quality and correct Error implementations is too difficult to do by hand. In particular I am a believer in heavy use of the cause chain, which in practice is too difficult to do consistently without help. But I'm willing to be convinced, either to not use any library or to use something different.

I note though that I have seen little passion for the cause chain elsewhere in the community, so it's not clear what the best practices are. Both cargo and rustup go to significant effort to build and report the cause chain (this is the core motivation for the error-chain crate), and cargo at least sometimes has excellent errors. I haven't seen other projects follow their lead, though they might exist.

cc @sticnarf

[brson]

I am relatively convinced that failure is not the solution to error handling in Rust, but for the mvp we can leave it in and worry about it later.

[brson]

FWIW in the side project I'm currently working on I use multiple distinct tools to make writing error types easier: https://github.com/brson/basic-http-server/blob/91ff4ac34fc470302dbbf57bf39c0f367c46070f/src/main.rs#L359.

In particular, there is an existing crate for derive(From) which is just fine for error types. The error-deriving crate I'm using there I think could be improved. But I like the approach of picking whichever smaller derive tools you need instead of a do-everything error macro.

[lnicola]

I like snafu as an alternative: it can derive the boilerplate code, and has a nice bonus of being able to use different variants with the same nested error (e.g. to differentiate disk vs. network errors).