Hacker News Reader

Comment by shepmaster | Hacker News Reader

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

View on HN

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.

Reply on news.ycombinator.com