8 comments

[ 4.5 ms ] story [ 29.8 ms ] thread
This just feels like recreating exceptions, but with more complicated syntax.
Yeah but only if you were to always use checked exceptions, and have mandatory try/catch around every function call, and have a much nicer syntax for throwing exceptions with added context. I've never seen any language that did that but I guess it would be possible.
How is this different from the even more ergonomic “#[from]” provided by thiserror?
Thankyou for pointing out a Rust, crate, error handler. Judging by the other comments, it's just as well you did,as I will look more closely at its use with virtual DOM. Thankyou.
I have never seen anything use Result<_,&'static str>, that is such an anti-rust thing to start with.
OP should really mention that they made stackerror. I couldn’t shake the feeling that this read like an ad for stackerror… and of course the author is the crate writer. This feels somewhat disingenuous without a disclaimer that you wrote the lib and there are other ways.

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.

Rust used to be pretty hard to read and write, now with ai coding agent not anymore.
>And errors are consumed by two distinct consumers with different needs: the developer debugging an application, and the caller making error handling decisions at runtime.

Three. Three distinct consumers. Get that in your head. When your application errors out on startup, it's the user who sees the error message. File system errors without seeing the path of the file are useless.