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!

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

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!

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

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

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)

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

High quality content! Thank you

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

@JeremyChone

8 күн бұрын

Thanks for the feedback.

Great video!

Great video. Nice pattern.

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.

love this!!

very nice, will try

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

Thanks.

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

27 күн бұрын

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

happy coding!

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.

thank you

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.

had my suvbscribe after 1:25

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: kzread.info/dash/bejne/ZIFksrWimq_UmdY.html Rust AI Buddy: kzread.info/dash/bejne/gnyWpc-Ck868YpM.html And the big Rust-Web-App blueprint github.com/rust10x/rust-web-app

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.

❤❤❤

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

Jeremy Chone have spoken, Lissan al Caib !

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.

@user-of6ls2ng5l

Ай бұрын

@JeremyChone thanks so much for the detailed reply)

@user-of6ls2ng5l

Ай бұрын

@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

Ай бұрын

@@user-of6ls2ng5l 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.

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

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

@JeremyChone

15 күн бұрын

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.

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.

Really hate Result type alias concept

@JeremyChone

Ай бұрын

I grew to really like it.

@nubunto

Ай бұрын

Why tho, genuinely interested in your thoughts