Errors.

[ruseinov]

I'd like to look into various error-handling options. Currently we are using a blend of generic anyhow errors and concrete type-safe errors. Here's one example of where we mix the two. It might not be the most interesting of examples, but imagining a scenario where we need to test various outcomes - having to validate generic errors could be suboptimal.

It's really hard to make a distinction here between library code and application code as we have it all in one repo and crate, with anyhow as global dependency. I'm not necessarily against that, but would like to see what others are thinking about this.

Here's some more fairly apparent context:

Generic errors

Upsides:

1. Easy to emit.
2. Easy to convert.
3. Somewhat eloquent.

Downsides:

1. No type safety.
2. Easier to choose the fast way and forgo proper error handling. (Subjective)
3. Harder to navigate, debug, test and refactor.

Concrete enum-based errors

Upsides:

1. Easy to test.
2. Easy to serialize and verify in other environments if need be.
3. Forces one to be more thoughtful in terms of various error-handling scenarios.
4. Typesafe

Downsides:

1. Verbose

[LesnyRumcajs]

I'd say we should be pragmatic.

In this project, it is rare that we need to differentiate between the errors we throw ourselves. The overhead of adding explicit error enumerations just because a particular piece of code seems like a library may not be worth it. If such a need arises, we can always add it then, likely with little changes to the calling code. This is, unfortunately, annoying to the person needing more concrete errors in their feature. On the other hand, writing and adding new cases to the error enums is cumbersome for everyone. I'd argue the latter has more impact on the team's velocity.

Some historical background - back one year ago, we didn't use anyhow at all. It was a mix of either Result<T, Box<dyn StdError>>, concrete error enums (though not really used) and a few places where we actually cared about the error. Usage of anyhow significantly improved readability and ease of development. See more in the issues closed.

This is not a strong opinion, and I'd be okay with being less pragmatic and more dogmatic if that's the team's decision.

[ruseinov]

Thanks for the explanation, that makes total sense. I didn’t have the opportunity to browse historical PRs yet, which is something that could be very educational in terms of decisions made over time.