You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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:
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).
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.
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.
The text was updated successfully, but these errors were encountered: