Comparison to thiserror

[Person-93]

Hi,

I stumbled across this project today and it looks really cool. I was really happy to see a comparison section in the guide, but I was hoping to see how it compares to thiserror.

I found this thread on reddit, but it's from two years ago so I'm not sure how relevant it is.

I found this discussion from the kube-rs project that looks like it might be more up to date.

Would you consider adding an official section to the guide for this? If you share your thoughts with me, I'd be happy to help draft it.

[shepmaster]

I would love to have a comparison section vs thiserror. My biggest worry is that I don't want to mischaracterize another crate, and I haven't used thiserror extensively enough to feel comfortable knowing what it can and can not do.

Do you have experience with thiserror? If so, maybe you can suggest some of the points that you like about it and I can correlate with equivalent SNAFU features.

To me, the ability to succinctly add additional data is the big thing that SNAFU brings here:

something_that_can_fail().context(FailedToDoSomething { extra, data })?;

This also corresponds to the fact that you can easily categorize one underlying error type into multiple higher-level errors:

some_operation().context(FailedToDoThingOne)?;
some_operation().context(FailedToDoThingTwo)?;

This is especially useful with how many crates have one big error type for every possible failure that could ever occur (e.g. std::io::Error, reqwest::Error).

[Person-93]

Here are a couple things that come to mind. I'll try to add more later as I think of them.

• [error(transparent)] makes it easy to use newtype structs as errors
• Easy to define several error structs and combine them into an enum. Each variant of the enum is a tuple variant with one member: the struct you previously defined
  • This allows easy re-use, one error struct can be used in multiple enums
  • This allows more fine grained encapsulation. The two options offered by snafu seem to be make it all public by making the data be members of a struct variant or make the entire error completely opaque. The first option means that the names and types of the data is exposed as part of the API, the second means that consumers of the API can't match on the error enum.