top | item 44986875

Ergonomic errors in Rust: write fast, debug with ease, handle precisely

32 points| garrinm | 6 months ago |gmcgoldr.github.io

27 comments

order

TheCleric|6 months ago

This just feels like recreating exceptions, but with more complicated syntax.

IshKebab|6 months ago

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.

catlifeonmars|6 months ago

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.

XorNot|6 months ago

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.

hardwaresofton|6 months ago

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.

QuaternionsBhop|6 months ago

I have never seen anything use Result<_,&'static str>, that is such an anti-rust thing to start with.

adastra22|6 months ago

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.

adastra22|6 months ago

How is this different from the even more ergonomic “#[from]” provided by thiserror?

echelon|6 months ago

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.

imtringued|6 months ago

>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.

faangguyindia|6 months ago

Rust used to be pretty hard to read and write, now with ai coding agent not anymore.

Analemma_|6 months ago

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.

_aobj|6 months ago

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.