Migrate away from failure to own Error type(s)?

[strohel]

I suggest to eventually provide own error type(s), (and let the boilerplate be filled in by thiserror).

Advantages:

• thiserror is not deprecated, as opposed to failure.
• thiserror does not end up in public API surface, it is merely an implementation detail. Meaning less opinionated API and ability to swap it for something other.

Disadvantages:

• slightly more code.

This is not necessarily Before Publish stuff: the need to be able to programmatically distinguish individual error variants may not be high. Recipient::send() family of functions already use a specific error, discussed in https://github.com/tonarino/actor/issues/20.

[bschwind]

Definitely agreed, most of this code was written two years ago and I feel failure has gotten itself embedded a bit too deep into our codebase. Either providing a plain Error enum, or a thiserror-derived Error sound great to me.

[mcginty]

On my most recent projects, I've just been using Error types that impl std::error::Error and in consumers of the crates, just using type Error = Box<dyn std::error::Error> can get you a long way without needing thiserror or anyhow. Maybe we can try to not even use thiserror and keep our dependency count as low as possible :).