Sure but I’ve also looked at projects that have 15-20 enums (or more) for their error types and it makes things very cumbersome. `anyhow` makes it painless to have arbitrary errors. It’s trying to take the context and stuff it in to the type system. Which isn’t necessarily a bad idea but it can become unwieldy.

I’ve done both in production projects and they both have their merits but 9 out of 10 times I’ll start with `anyhow` if I’m writing library code and then refactor to enums later if I need it instead of the other way around.

EDIT: That said Snafu does look really cool for the cases where you do have a codified sum type of all possible errors.

DOUBLE EDIT: I already had Snafu starred on GH lol

> 15-20 enums (or more) for their error types and it makes things very cumbersome

Like everything, it can be a balancing act. I tend to be free about creating error types (one per module, usually, but it's not strange for me to create more). When you implement `std::error::Error` (to be able to make error trait objects) and have a tool like SNAFU (to make error enums), then having more error types isn't much of a hindrance in my experience.

> I’ll start with `anyhow` if I’m writing library code and then refactor to enums later

The newest (beta) version of SNAFU actually strives to make this case even smoother. There's a `whatever!` macro that you can use to create stringly-typed errors and then migrate case-by-case to an enum. Check out the docs for some example usage.

I used the wrong wording: They have 15-20 *enum variants* per enum definition. Or more. I worked with a project that had close to 30-something enum variants.

That’s just… wildly annoying to deal with IMO.

That sounds like a different design issue. Errors are certainly part of the API and it looks like they’re not encapsulated well enough.