Alternative to Failure for Error Handling

[zicklag]

Hey there, I was wondering if you had considered anyhow for error types.

I am using Anyhow for my project which requires that errors implement std::error::Error, and Failure's don't so I have to .map_err(Fail::compat) for every Docker error that I want to handle with the ? operator.

I think that Anyhow is a more pragmatic replacement for Failure which grants lots of the same advantages while being better integrated with other libraries, because Anyhow errors do implement std::error::Error and are therefore compatible with any other library that takes Errors.

Anyway, this is just a friendly suggestion. I'd like to hear your thoughts. 🙂

[emk]

(I'm the maintainer of boondock, the just-barely-maintained original project from which dockworker was forked. I am not associated with dockworker, but I think it's cool. I'm currently trying to decide if I want to fully deprecate boondock and just send PRs to dockworker, which is why I'm looking at the bug tracker.)

I agree that failure should be phased out of most projects. As I understand it, the recommended replacements are:

• thiserror for libraries. This provides support for nice error enums with specific error types that the caller can match against.
• anyhow for applications. anyhow::Error is a fairly opaque type, but it's very easy to use if you just want to print errors to the user, or wrap extra information around an error. Unfortunately, anyhow only supports backtraces on nightly Rust right now.

So I think that thiserror might be a better choice for dockworker.

[zicklag]

Ah, @emk you are right about thiserror being a better alternative for dockworker. That was my mistake.

In this case it has the same desired advantage for my situation because all thiserror is just a helper to implement std::error::Error for your own types and would allow me to use the ? operator when my functions in my application use Anyhow errors.

[eldesh]

At 122, @dalance changed the error representation to use thiserror.
Thank you for your suggestion @zicklag @emk .