4 ms·

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 h

by dljsjr 5y ago

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

shepmaster 5y ago
> 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.
- dljsjr 5y ago
  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.
  - catlifeonmars 5y ago
    That sounds like a different design issue. Errors are certainly part of the API and it looks like they’re not encapsulated well enough.

by dljsjr 5y ago

shepmaster 5y ago

> 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.

dljsjr 5y ago
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.
- catlifeonmars 5y ago
  That sounds like a different design issue. Errors are certainly part of the API and it looks like they’re not encapsulated well enough.