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!
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!
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)
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.
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."
Hi Jeremy, love your videos. I have some problems where I have two structures that is communicating with each other. A battle prompts the user for an action, and the user ai uses the context of a battle to determine an action. Sometimes, the user might request something from the battle that might fail. However, implementing from for both error types results in the infinite recursion error (obviously). Do you have a way you prefered to solve this problem? Some type or pointer or avoid the situation altogether? Thanks again for the video and keep up the good work!
@@Middlew can you show me some pseudo code to illustrate the issue. We can write From A for B, and From B for A. So, I think you are referring to something else.
/error[dot]rs in battle folder: pub enum Error { ... #[from] User(error::User), ... } /error[dot]rs in user folder pub enum Error { ... #[from] Battle(error::Battle), ... } I used something similar in your axum course if I remember correctly, where you converted from different error types. That might have been for a better reason though, I dont quite remember.
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?
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.
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 !
Thanks. You can find some examples of this usage in other videos/codebases. For instance: AI Function Calling: th-cam.com/video/2M0PSijLnis/w-d-xo.html Rust AI Buddy: th-cam.com/video/PHbCmIckV20/w-d-xo.html And the big Rust-Web-App blueprint github.com/rust10x/rust-web-app
Hi, Thank you for your videos. I have question, why we need to do error handling like this? I am new to Rust. Any reasons? I mean last rust.rs file separation part.
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.
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?
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`.
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 ?
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 ?
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.
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?
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.
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?
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.
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)
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.
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.
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.
@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.
@@ИванРагозин-я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.
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).
![ลองสุ่มไอโฟน 990 โกงมั้ย? [ โกงมั้ยครับ ep.101 ] | DOM](http://i.ytimg.com/vi/bfsWe0j492k/mqdefault.jpg)
More videos on best practices in Rust please! Perhaps some on Tests, Tracing, Scaling Rust Backends, etc.
Best Practices? yes please!
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!
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!
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)
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!
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.
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."
Great video! May I ask how you would incorporate backtrace into the error definition?
Awesome, I was struggling with how to handle error gracefully, and you help me out a lot
Amazing video! More best practices videos please and thank you very much!
this is amazing ! thanks so much for taking the time to release such a good quality content.
So what do you think about thiserror instead of derive_from?
This is awesome. Thanks for making these videos. Very clear, concise and easy to understand and the actual content is amazing.
Thanks for the feedback.
Cool I was looking a video in that way.
Thank you!
Hi Jeremy, love your videos. I have some problems where I have two structures that is communicating with each other. A battle prompts the user for an action, and the user ai uses the context of a battle to determine an action. Sometimes, the user might request something from the battle that might fail. However, implementing from for both error types results in the infinite recursion error (obviously). Do you have a way you prefered to solve this problem? Some type or pointer or avoid the situation altogether? Thanks again for the video and keep up the good work!
@@Middlew can you show me some pseudo code to illustrate the issue. We can write From A for B, and From B for A. So, I think you are referring to something else.
/error[dot]rs in battle folder:
pub enum Error {
...
#[from]
User(error::User),
...
}
/error[dot]rs in user folder
pub enum Error {
...
#[from]
Battle(error::Battle),
...
}
I used something similar in your axum course if I remember correctly, where you converted from different error types. That might have been for a better reason though, I dont quite remember.
@@JeremyChone Hi sorry, I'm not sure you got my previous message so I'm trying again 😅
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?
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.
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 !
Thanks.
You can find some examples of this usage in other videos/codebases. For instance:
AI Function Calling: th-cam.com/video/2M0PSijLnis/w-d-xo.html
Rust AI Buddy: th-cam.com/video/PHbCmIckV20/w-d-xo.html
And the big Rust-Web-App blueprint github.com/rust10x/rust-web-app
Hi, Thank you for your videos. I have question, why we need to do error handling like this? I am new to Rust. Any reasons? I mean last rust.rs file separation part.
thiserror crate is very usable for a prod too
Btw great video!
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.
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?
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`.
High quality content! Thank you
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 ?
Jeremy Chone have spoken, Lissan al Caib !
Great video. Nice pattern.
very nice, will try
Thanks.
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 ?
Great video!
For one off errors, do you create a new error variant, or do you just use a generic msg error with a string?
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.
happy coding!
love this!!
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?
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.
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?
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.
how do you briefly display types on 10:39?
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)
@@JeremyChone thnaks
This was great
had my suvbscribe after 1:25
Error::LimitTooHigh(LimitDescription)
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.
@@JeremyChone newtype is also good when you need to generate code for other platforms, like graphql or typescript
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.
Why didn't you show error creation for fs. What will you call the enum ? ErrorFs ?
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.
@JeremyChone thanks so much for the detailed reply)
@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.
@@ИванРагозин-я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.
thank you
❤❤❤
Hi! Is #[derive(From)] external crate proc macro? Or something to enable in std library?
Ok it’s from derive_more. Thanks!
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).
Fait tes tutos en francais la vague rust arrive dans le main stream
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.
Really hate Result type alias concept
I grew to really like it.
Why tho, genuinely interested in your thoughts