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.
Sometimes it’s nice to have one control flow mechanism rather than too. One could argue that traditional exceptions are more complicated with a their alternative control flow and syntax.
The common problems with exceptions isn’t the easy part of try/catch, it’s the execution model and “any function could throw” that causes most contention. Error values are logically simpler and fully document if and what errors the function can return. Checked exceptions solve that too, but in practice nobody used them even where available. And you still end up with hidden control flow with exceptions, the exceptional path through a function is syntactically invisible and difficult to audit without very strong language tooling.
And also the issue with checked exceptions is that one can't be generic over the checked exception, at least in Java. So it's impossible to write out a universally useful function type that's strictly typed on the error. This definition of `ThrowingFunction` for Java [1] needs just have `throws Exception`, allowing just about anything to be thrown.
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.
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.
I’m an actual Rust programmer, and I’ve done that. Especially for the first iteration of something when I’m not yet sure what will be included, or when the errors are just going to be printed to the terminal as the program exits.
How long are your compiles? The longest I’ve ever seen is a massive Bevy project with 700 dependencies, and it still compiled in <5min from an empty cache, and then 2-3 second incremental builds (mostly link time).
>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.
Have you had success doing non-trivial Rust with AI agents? In my experience they're all pretty bad at it once you get beyond the basics and start having tricky lifetimes and complicated types, but I'm interested to hear what people have done to make it better.
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.
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.
Sometimes it’s nice to have one control flow mechanism rather than too. One could argue that traditional exceptions are more complicated with a their alternative control flow and syntax.
I mean broadly that's my entire problem with errors as values: every implementation wastes a ton of syntax trying to make them like exceptions.
The common problems with exceptions isn’t the easy part of try/catch, it’s the execution model and “any function could throw” that causes most contention. Error values are logically simpler and fully document if and what errors the function can return. Checked exceptions solve that too, but in practice nobody used them even where available. And you still end up with hidden control flow with exceptions, the exceptional path through a function is syntactically invisible and difficult to audit without very strong language tooling.
And also the issue with checked exceptions is that one can't be generic over the checked exception, at least in Java. So it's impossible to write out a universally useful function type that's strictly typed on the error. This definition of `ThrowingFunction` for Java [1] needs just have `throws Exception`, allowing just about anything to be thrown.
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...
Go unironically gets this right - you just treat them like a normal value instead of trying to make them more "ergonomic".
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.
I have never seen anything use Result<_,&'static str>, that is such an anti-rust thing to start with.
LLMs love to do this. I assume they are trying to write JavaScript or Python or whatever, but in Rust.
I have never seen an actual Rist programmer do this, and that was clue #1 that TFA was AI generated without review.
I do when prototyping. Long term you don't really want to pass around &str errors, but they are quick and dirty and easy to get rolling with.
You can also use eyre! with it's accompanying Result for even easier and faster development.
Seems just as quick to make an enum with thiserror string conversion? Not much boilerplate at least.
I’m an actual Rust programmer, and I’ve done that. Especially for the first iteration of something when I’m not yet sure what will be included, or when the errors are just going to be printed to the terminal as the program exits.
How is this different from the even more ergonomic “#[from]” provided by thiserror?
Are all of these proc macros worth it? The compile times for proc macros explode.
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.
Cognitive load is more expensive than compilation time.
Compilation time turns into cognitive load via frustration. Death by a thousand cuts.
How long are your compiles? The longest I’ve ever seen is a massive Bevy project with 700 dependencies, and it still compiled in <5min from an empty cache, and then 2-3 second incremental builds (mostly link time).
https://xkcd.com/303/
(compilation time is good for brain switch off time - i.e. reducing cognitive load).
I find it's great for letting ADHD take over steering the ship and losing total focus on what needs to be done.
Which is more or less what this XKCD encapsulates.
Frankly, std::io:Error::other is good enough most of the time.
>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.
Rust used to be pretty hard to read and write, now with ai coding agent not anymore.
Have you had success doing non-trivial Rust with AI agents? In my experience they're all pretty bad at it once you get beyond the basics and start having tricky lifetimes and complicated types, but I'm interested to hear what people have done to make it better.
yes i did, try aistudio > gemini pro 2.5 from web console on your programm lemme know how well it works.
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.