Rust Error Handling - Best Practices

Here are some best practices for error handling in Rust programming that I've found effective:
- For tests and examples, use "box dyn error" instead of "anyhow."
- Prefer the "?" pattern over "unwrap" or "expect," even in tests and examples, to align with production coding standards.
- "Box dyn error" is excellent for error passthrough, as are `map_err` and `ok_or` with static strings and formatted strings.
- In production code, use an enum with fully descriptive variant names and favor struct variants with clear names over tuple variants.
- Avoid relying on the display to convey the meaning of error variants.
- In web or device applications, human error rendering might not occur at the enum/type level, so using Debug for display may suffice.
- For web or device applications, using Serialize for errors that need to be logged or sent to the client for display can be a powerful and straightforward pattern.
- Prioritize clarity in error naming (variants) and focus on consistency as the code develops.
- Don't be afraid of medium-length enum variant names; remember, type refactoring is straightforward.
- In summary, start with progressive and clear practices, and become more structured as the code matures.
== Jeremy Chone:
- Patreon - / jeremychone - Any help is a big help (for Rust educational content)
- Twitter - / jeremychone
- Discord general-rust - / discord
- Discord rust10x - / discord
- Rust10x - rust10x.com - Rust resources for production coding.
Big thanks to CrabNebula (crabnebula.dev/) for sponsoring this channel.
== Rust10x AI / OpenAI / Ollama
- Rust OpenAI API Tutorial: • Learn Rust OpenAI API ...
- Rust Ollama Tutorial: • Rust Ollama By Example...
== Rust10x Web App production coding:
Episode 01: • Rust Axum Production C...
Episode 02: • Rust Sea-Query + SQLX ...
Episode 03: • Rust Workspace Product...
Episode 04: • Rust Argon 2 Password ...
Episode 05.1: • Rust RPC Router - Axum...
Web Site: rust10x.com/we...
GitHub: github.com/rus...
Discord rust10x - / discord
Patreon - / jeremychone - Any help is a big help (for Rust Production Coding educational content)
== Other
Other popular Rust Programming videos:
- Rust Web App Production Coding Blueprint - • Rust Axum Production C...
- Rust Axum - Full Course - • Rust Axum Full Course ...
- Rust Type State Builder Pattern - • Rust Programming: Type...
- Quick Start Code Layout - • Rust - Simple Code Lay...
- AWESOME-APP Full Overview - Rust template for building Awesome Desktop Application: • Building Awesome Deskt...
- Tauri Quick Introduction (Desktop App wit Rust Programming): • Rust Tauri 1.0 - Quick...
- Rust Web App tutorials series: • Rust Web App - 1/3 - D...
- Rust Bevy Full Tutorial - Game Development with Rust: • Rust Bevy Full Tutoria...
- Rust for Java Developers series: • Rust for Java Develope...
Playlists:
- Rust AI Programming Series: • JC - Rust & AI Program...
- Rust Web App Production Coding Series: • JC - Rust Production C...
- Rust For Desktop App: • JC - Rust Programming ...
- Everything Rust Programming - Tutorials, Courses, Tips, Examples: • JC - Rust - Everything...
- Rust Programming for Web Development: • JC - Rust Programming ...
- Rust Courses: • Rust Course 2021 by th...
- Rust for Java Developers: • Rust for Java Developers
Rust10x - Coding Resources for Production Coding in Rust. ➜ rust10x.com
Other notes:
- ScreenBrush for the green lines. (Gromit seems to be the equivalent on Linux)
- Sketchapp for some graphics.
- Davinci Resolve and Fusion video editing.
- VSCode with Google Material icon themes (with some customization)

[@yudhiesh1997]

More videos on best practices in Rust please! Perhaps some on Tests, Tracing, Scaling Rust Backends, etc.

[@Aucacoyan]

Best Practices? yes please!

[@dannelalbert7111]

This is by far the best explanation of how to do robust error handling in Rust. I've always been a bit lost without anyhow and thiserr. This seems like a fantastic workflow that checks all the boxes I have been looking for progressing from test to production code without getting bogged down. Thank you for sharing this!

[@Maximus98245]

Great video and very well presented! Being a beginner in Rust, I kind of was lost after the first 5 minutes but I understood enough that I need to dig deeper into error handling, it's not just throw in "anyhow" or "thiserror" crate and you are good to go. I will keep coming back to this as I learn! Thanks again!

[@norminemralino2260]

Another great video. I’ve noticed Jeremy talking about error handling in his last few videos, so it’s nice to see him do a video on error handling specifically. Though I think it could use a part 2. Maybe go ahead and implement structured Error type and add an example of a custom display for it and an example of calling the error. Maybe also add a error from a different module (he kinda talked about it)

[@jamesray1820]

Great, video I have been using these patterns in part since I started watching your videos. It is great to have it completely explained. Thank you!

[@yelan5034]

Awesome, I was struggling with how to handle error gracefully, and you help me out a lot

[@gabrielkwong1878]

Amazing video! More best practices videos please and thank you very much!

[@SniffleSneeze]

this is amazing ! thanks so much for taking the time to release such a good quality content.

[@arcaneminded]

Thanks mate. Small nit-pick you mentioned using embedded 'one day', but if you're using embedded, I'd really try to stay away from using trait objects and use the anyhow crate. Also the pass through `?` get's a little more complicated when dealing with embedded.

[@JeremyChone]

Ho, good points. I can understand the confusion. I meant just the type alias of Result, not the Box part for the error. Also, the whole ? and error handling seems to be a different beast in embedded, so the comment was a little misleading, I agree. I should have removed this comment, and just said, "same as std, and I like using core when possible as it lets me know what is not dependent on std."

[@dkoleary88]

This is awesome. Thanks for making these videos. Very clear, concise and easy to understand and the actual content is amazing.

[@JeremyChone]

Thanks for the feedback.

[@gbinux]

Great video! May I ask how you would incorporate backtrace into the error definition?

[@maxali6591]

Cool I was looking a video in that way. Thank you!

[@guacharo.w3871]

thiserror crate is very usable for a prod too Btw great video!

[@JeremyChone]

Yes, if your product requires "English" display for your errors, this error is okay. However, I think that "English" display is useful only if it is intended to be shown to the end user. If it is just for developers and IT people, then the debug serialization as display is sufficient in most cases. This is why I like derive_more. It's relatively equivalent in result but we can choose what we want.

[@Jubijub]

Thank you so much for this video, this is so useful. Beginner content is nice, but the examples are too trivial, and in particular don't cover well how to organize the code. Those are really neat patterns to know. More content like this please !

[@JeremyChone]

Thanks. You can find some examples of this usage in other videos/codebases. For instance: AI Function Calling: kzbin.info/www/bejne/aH6TgYafn7Ghn9U Rust AI Buddy: kzbin.info/www/bejne/hnnFdKB_mNCJaJI And the big Rust-Web-App blueprint github.com/rust10x/rust-web-app

[@jensen7141]

High quality content! Thank you

[@TheOmfg02]

Great video!

[@TheZdannar]

Great video. Nice pattern.

[@addDexter]

Jeremy Chone have spoken, Lissan al Caib !

[@pkozelka]

very nice, will try

[@irlshrek]

love this!!

[@Boronesss]

happy coding!

[@floristrading8418]

had my suvbscribe after 1:25

[@froop2393]

great! I like it. I have one question: You mentioned not to use an error module. But then you created one and did a (reexport?) to get rid of the error::Error import. Is that what you suggest as best practise?

[@JeremyChone]

Good point. I noticed after rewatching the video that this could be misleading. What I meant was that I do not expose my module Error within a submodule "error". However, for code organization, I put the code in error.rs and then re-export it at the root of the module. I should have clarified that. I showed it, but did not clarify it.

[@MrBenoitL]

Thanks for the video, it was very informative. I am quite new to Rust and struggle to write tests to see if a function returns the correct error (with the correct data inside) ? Rust is asking me to implement PartialEq for std::io::Error if write assert!(some function == Err(Error::Custom("some error")); what am I missing ?

[@cariyaputta]

Thanks.

[@mykhailohnap]

If one test has a couple of places where the identical error could be returned, how do you know which place has failed? It seems that `unwrap` or `anyhow` could be better because they would allow us to see the exact place (line with `unwrap` and whole backtrace with `anyhow`) where the error occurred, no?

[@JeremyChone]

First, I would not use `unwrap` because of its backtrace support. It can make the code brittle. There are a few cases where `unwrap` is acceptable (e.g., when failing early is a must), but even then, it can be avoided for the sake of consistency. Regarding `anyhow`, yes, the `anyhow` macros do support backtraces, but I would avoid using the "anyhow magic" in my app or library errors, as it introduces another way to handle errors in Rust. If backtrace support is necessary, creating a custom macro, similar to `anyhow`, but using normal errors, might be a good approach. I haven't looked into this deeply, as it hasn't been a bottleneck in my code, and for me, the net value of having something cleaner and closer to pure return and error enums is higher. However, there is no absolute truth. Some teams might require backtraces, and in that case, you have to weigh both options. Either way, I would not recommend using `unwrap` in production code.

[@June-c2q]

This was great

[@juliuso.1183]

Hey Jeremy Thanks for the great series! I am learning a lot that I am trying to incorporate into our production server designs.. Is there a reason as to why you use `impl std::fmt::Display` instead of `impl ToString` for custom error messages?

[@JeremyChone]

We could use `impl ToString`, but it is a little less flexible and less common/idiomatic than `impl Display`. For example, with `impl ToString` for `format!`/`println!`, we have to call `to_string()`, which requires adding them as an "argument," whereas with `impl Display`, we can just inline them in `{...}`. Also, typically, if we want a type to have `to_string()`/`ToString`, we would `impl Display for MyType` rather than implementing `ToString`. There's a blanket implementation of `ToString` for all types that implement `Display`, so we're good. Now, the other option that might be used is `impl Into`, which is more suitable for cases where the function needs to own the `String` but wants to give the caller the option to pass an owned `String` to avoid a new allocation if possible. If the caller passes a reference to a `String` or `str`, `into()` will allocate a new `String`.

[@moquette31]

in case you want to do a [no_std] library, when you "impl std::error:Error for Error {}" you don't have access to std, and core::error::Error is unstable. How do you handle this case ?

[@LucasOe]

For one off errors, do you create a new error variant, or do you just use a generic msg error with a string?

[@JeremyChone]

Depends if I am early in my code. If I am, then I use the Custom variant and the from static str, or formatted string. Then, when the code matures, I remove the Custom and all become variants, each with a descriptive variant name. I first focus on being descriptive in my variant names, and then work on consistency as the code design matures. Variant naming refactoring are simple and fast.

[@betterinbooks]

thank you

[@adamsmith7630]

I don't think I understand why one might prefer writing your own boilerplate for your Error enum rather than using thiserror. Is it just to have finer control of the Display implementation?

[@JeremyChone]

Yes, thiserror takes over the display, which in my approach I don’t typically need as Debug as Display is plenty enough. With derive_more, I can still remove the From and Dispatch boilerplate, but I have the choice. About the display annotation: Annotating each variant with display is redundant and can lead to the anti-pattern of capturing meaning as text rather than having fully descriptive variant names and structures. For simple command-line applications, it’s fine, and the derive_more display removes the boilerplate like this error. For web or even desktop apps, typically we want to move the structure of the error to another system (e.g., log service/system) and have it displayed to the end user. For this, serializing to JSON is often a great approach.

[@CuriousSpy]

Error::LimitTooHigh(LimitDescription)

[@JeremyChone]

I would use that pattern only if LimitDescription is used in other variants. Otherwise, I inline the struct members as variant struct members. It avoids unnecessary type proliferation. However, this could be considered a personal preference. Both are valid approaches.

[@CuriousSpy]

@@JeremyChone newtype is also good when you need to generate code for other platforms, like graphql or typescript

[@JeremyChone]

Ha, good points. If the error type needs to be expressed in a type system that does not support algebraic types, then the decoupling might help. And, even then, we still have the different variant inner types to manage (albeit, union types on named types are easier to read than inline object types). For TS, I tend to serialize my Rust enum as "name/detail" in JSON, and I need to check if the toJSON schema can inline the type so that the JSON schema to TS type can express the correct structure. However, I typically concentrate on making the Rust part as clean and idiomatic as possible, and treat those external parts as "followers," and I am willing to make some concessions for them. But different approaches are valid as well.

[@NOISCALE]

❤❤❤

[@sunofabeach9424]

how do you briefly display types on 10:39?

[@JeremyChone]

I use Toggle VSCode extension, and then add a key binding to toggle the inlay. You can find more info there: rust10x.com/vscode#keybinding-for-toggling-the-inlays (Note: this does not require the Rust10x vscode extension)

[@sunofabeach9424]

@@JeremyChone thnaks

[@ИванРагозин-я8я]

Why didn't you show error creation for fs. What will you call the enum ? ErrorFs ?

[@JeremyChone]

Ah, it depends. I do not include error types for all submodules, focusing more on the main submodules that are likely need to have their own Error. This was just an example, but if I decided to have `crate::fs_utils` (I would rename it to avoid confusion with `std::fs`), I would do something like: `src/fs_utils/error.rs` to define `Error` with the `Result` type alias. And in `src/fs_utils/mod.rs` I would do: ```rust mod error; pub use self::error::{Error, Result}; ``` This way, if I am outside of the `fs_utils` module, I would use `Result` or `Error` as `fs_utils::Result` or `fs_utils::Error::...`. If I am within the `fs_utils` module, I would import and use `Result` or `Error` as needed.

[@ИванРагозин-я8я]

@JeremyChone thanks so much for the detailed reply)

[@ИванРагозин-я8я]

@JeremyChone please record a video: best practices for structuring a project on Rust. It's very hard to decide what names to give folders/modules for certain features. Thanks.

[@JeremyChone]

@@ИванРагозин-я8я Yes, there isn't a hard rule about when it's a good time to create an error for a module. However, there are some rules of thumb, so I need to articulate those. Also, these rules are okay to be broken once in a while. Additionally, some can be considered personal preferences. One video I want to make is "Module Best Practices," and in this video, we can definitely tackle this subject.

[@rougegorge3192]

Fait tes tutos en francais la vague rust arrive dans le main stream

[@JeremyChone]

Thanks, could be a good idea. But this would probably need to be in another channel now and quite a bit of work to do both.

[@MrHirenP]

Hi! Is #[derive(From)] external crate proc macro? Or something to enable in std library?

[@MrHirenP]

Ok it’s from derive_more. Thanks!

[@JeremyChone]

Yes, as @MrHirenP said, it's part of the derive_more crate, which offers some useful procedural macros. I like it because it provides the trivial impl From (similar to the thiserror transparent), but separates it from the Display implementations (which thiserror takes over).

[@kuqmua755]

Really hate Result type alias concept

[@JeremyChone]

I grew to really like it.

[@nubunto]

Why tho, genuinely interested in your thoughts