4 ms·

Propagation without needing to use boxed trait objects can also be accomplished using `anyhow`[1]/`eyre`[2], which have nice downcasting API’s for recovering th

by dljsjr 5y ago

Propagation without needing to use boxed trait objects can also be accomplished using `anyhow`[1]/`eyre`[2], which have nice downcasting API’s for recovering the original error type if you know what the possibilites could be. I only bring it up because they aren’t mentioned until the end of the article and only in passing but they offer really nice features for attaching context and downcasting that makes up for the pseudo-type-erasure. 1: https://github.com/dtolnay/anyhow https://github.com/dtolnay/anyhow 2: https://github.com/yaahc/eyre https://github.com/yaahc/eyre

shepmaster 5y ago
> Propagation without needing to use boxed trait objects You can also use enums, as shown in the post. You don't need trait objects. EDIT 1 > without needing to use boxed trait objects [...] `anyhow` It's my understanding that anyhow uses trait objects. The first sentence of its document says "This library provides anyhow::Error, a trait object based error type" EDIT 1 END > which have nice downcasting API I'm not a fan of downcasting when not _absolutely_ necessary. See my sibling comment about SNAFU for an alternate that allows keeping different errors separate while unifying them.
- 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

> Propagation without needing to use boxed trait objects You can also use enums, as shown in the post. You don't need trait objects. EDIT 1 > without needing to use boxed trait objects [...] `anyhow` It's my understanding that anyhow uses trait objects. The first sentence of its document says "This library provides anyhow::Error, a trait object based error type" EDIT 1 END > which have nice downcasting API I'm not a fan of downcasting when not _absolutely_ necessary. See my sibling comment about SNAFU for an alternate that allows keeping different errors separate while unifying them.

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.