The biggest thing to me is that many people lump errors by type (“all IO errors are equivalent”) which is very wrong to me. SNAFU encourages and streamlines bucketing your errors into detailed chunks.
Along the way, it makes adding details to your error easier (automatic calls to Into without a closure; optional implicit details).
It combines string-like errors (anyhow) and structured errors (thiserror) in one library.
It has basic command line error formatting that shows the causal chain without duplication.
I don’t use eyre so I don’t feel comfortable comparing to it.
Is there a way snafu could be redesigned not to rename Error to Snafu in custom error variants? It's annoying for like IDE reasons, but maybe technically challenging to fix.
I think you are asking for this config [0] (let me know if not, maybe provide an example), but I’d caution against renaming it back to “Error”. The context selectors are not themselves errors, they are more-or-less fancy error constructors. It’s the same logic I’d use to call it `Error::new` instead of `Error::error`.
Having the context selectors called the exact same as the variants was the way the original version of SNAFU worked, but it was also the number one cause of confusion and support requests.
Automatically generates structs for typing error contexts instead of just having strings. This forms a chain of causes, each of which contains additional context about what was happening when the error was returned.
I personally have used it because it can provide backtraces in stable Rust. It also can be used either similarly to anyhow (with the `whatever` macro) or more like thiserror (with explicit errors as enum variants). I don't have experience with eyre so can't provide a comparison there.