I'd rather hand-roll errors than deal with more proc macros. Or better yet, have code gen pay the cost once and never deal with it again.
(compilation time is good for brain switch off time - i.e. reducing cognitive load).
Which is more or less what this XKCD encapsulates.
I have never seen an actual Rist programmer do this, and that was clue #1 that TFA was AI generated without review.
The general advice is good (except for the awkward use of std error), so for anyone who wants to know what rustaceans are actually using:
- std error when it’s required
- anyhow for flexibly dealing with large classes of errors and rethrowing (often in bin crates or internally in a lib crate ), use anyhow::Context to tag errors
- thiserror for building and generating custom errors (in a lib crate)
- miette/eyre for more advanced features
Watch out for exposing error types in public API because then you are bound to push a breaking change if the upstream does.
Anyhow will probably never have a v2 at this point IMO, the entire Rust ecosystem might have to rev!
[EDIT] dont want to suggest that people avoid stackerror, just want to show what other ecosystem projects there are! stackerror seems to fit the hole of anyhow.
TheCleric•5h ago
XorNot•5h ago
MindSpunk•3h ago
marcianx•1h ago
Most functional-inspired languages would just have a single `f: T -> Result<U, E>` interface, which supports both (1) a specific error type `E`, which can also be an uninhabited type (e.g. never type) for an infallible operation, and (2) where `U` can be the unit type if the function doesn't return anything on success. That's about as generic as one can get with a single "interface" type.
[1]: https://docs.spring.io/spring-framework/docs/current/javadoc...
catlifeonmars•1h ago