Due to an accident of history, I'm the only person who merges changes to failure and performs releases these days and I'm not very good at it. I also think that moving failure to use the the recently revised Error trait instead of Fail isn't worth it because of the work needed to be done by downstream consumers. In my view, downstream consumers are better off updating their error-handling code to newer and more actively maintained crates like thiserror, anyhow, eyre, or snafu instead of updating to failure 0.2.
Despite all that failure has done for the ecosystem, I've convinced myself that failure should be marked as deprecated and direct users to alternatives. Does anyone disagree?
I agree. failure showed us what good error handling should look like, and now with the necessary changes merged into the standard Error trait, several new error-handling libraries arose that provide all the benefits of failure without the non-standard Fail trait.
I would suggest updating the README.md with an explanation of the history, and some examples of how to transition to other libraries. (For instance, how to transition to thiserror if you used custom error types and derive, or to anyhow or eyre if you used a catch-all error type.)
Thanks all, sounds good. Next steps for me are to:
Create a PR with a deprecation notice, suggesting that people migrate to any of the libraries mentioned, with anyhow/thiserror taking priority because of @withoutboats's input above and original authorship of Failure. This will have a migration guide to anyhow/thiserror.
Cut another minor release of failure, marking it deprecated on crates.io and docs.rs in a prominent location.
(Optionally) Cut a PR to https://play.rust-lang.org/ to remove failure. Not sure what the policy for removing crates in the playground are, however.
@withoutboats: I'll say as the original author of failure that I agree, and that I personally would recommend anyone who likes failure's API to migrate to anyhow.
@josh: And thank you for not only developing failure , but contributing to the improvement of the error ecosystem overall.
Perhaps have some sort of warning when useing the crate directly? It would be clear that it's deprecated while still allowing necessary usage (a la transitive dependencies).
Since I don't see another place for reporting typos, there's an unfinished sentence in the middle: "but based on the std Error trait instead of on." [sic]
Unfortunately cargo audit doesn't consume this information directly yet (although it could rather easily, and probably should).
If it's officially deprecated and there's a desire to do so, we can add an unmaintained crate warning for it, but failure is so pervasive it might be a bit noisy. Perhaps we could wait a bit for people to naturally transition and then file it.
That said, for the time being I plan to stick with failure, because failure::Error supports backtraces on the stable compiler, and anyhow::Error doesn't.
Might it make sense to wait for "feature parity" first?
(Is there another error library with backtraces on stable that I missed?)
You're welcome to stick with Failure, but I don't intend to publish any updates to failure in the future.
Snafu has backtraces. @yaahc's eyre and tracing-focused jane-eyre are interesting, more experimental alternatives. I believe jane-eyre builds on tracing-error.
(Full disclosure: I'm decently involved with tracing.)