3 ms·

Why not `thiserror` for executables as well? It happened to me a few times that I started to write an executable program, but then realized I want to embed its

by da-x 6y ago

Why not `thiserror` for executables as well? It happened to me a few times that I started to write an executable program, but then realized I want to embed its functionality in a library. Converting from `anyhow` to `thiserror` at that stage would be extra work that can be avoided.

jgilias 6y ago
I guess this depends somewhat on the situation. If the design is pretty clear upfront with a part that can be implemented as a core library, I'd make the library use `thiserror` from the beginning. However, if it's not really clear and I have to start with exploratory coding, then keeping track of error types that may come and go feels like unnecessary overhead, when I can just use `anyhow`. But! To each their own!
- status_quo69 6y ago
  I've used `thiserror` with great success in small side web projects since you can create a new enum of Errors that can be converted from a class of underling library errors. Then, inside of my regular application code, I sprinkle in `anyhow` to make my life easier. For example, if I wanted to say, return a 500 status code for all diesel database errors, I can convert the diesel error into my custom error type, then throw it back up the stack using `anyhow`. This works _really_ well in conjunction with Rocket's Responder impl. EDIT: This is pretty close to what TFA is saying as well, I should have read more in the article, heh
masklinn 6y ago
> Why not `thiserror` for executables as well? You can absolutely do that if you want, it's just that usually when writing an executable you don't care about creating the precise error types thiserror provides (especially doing so executable-wide), you'd handle the errors you get from reqwest or sqlx or whatever when you get them, and those you don't handle you just want to bubble up to an executable-wide handler.
marcosdumay 6y ago
Usually, you don't have any good thing to do with the error, so keeping it around just makes your code worse.
TheCoelacanth 6y ago
thiserror is quite a bit more work to use. There's nothing wrong with using it for applications, but it's often overkill for that use case

by da-x 6y ago

jgilias 6y ago

I guess this depends somewhat on the situation. If the design is pretty clear upfront with a part that can be implemented as a core library, I'd make the library use `thiserror` from the beginning. However, if it's not really clear and I have to start with exploratory coding, then keeping track of error types that may come and go feels like unnecessary overhead, when I can just use `anyhow`. But! To each their own!

status_quo69 6y ago
I've used `thiserror` with great success in small side web projects since you can create a new enum of Errors that can be converted from a class of underling library errors. Then, inside of my regular application code, I sprinkle in `anyhow` to make my life easier. For example, if I wanted to say, return a 500 status code for all diesel database errors, I can convert the diesel error into my custom error type, then throw it back up the stack using `anyhow`. This works _really_ well in conjunction with Rocket's Responder impl. EDIT: This is pretty close to what TFA is saying as well, I should have read more in the article, heh

masklinn 6y ago

> Why not `thiserror` for executables as well? You can absolutely do that if you want, it's just that usually when writing an executable you don't care about creating the precise error types thiserror provides (especially doing so executable-wide), you'd handle the errors you get from reqwest or sqlx or whatever when you get them, and those you don't handle you just want to bubble up to an executable-wide handler.

marcosdumay 6y ago

Usually, you don't have any good thing to do with the error, so keeping it around just makes your code worse.

TheCoelacanth 6y ago

thiserror is quite a bit more work to use. There's nothing wrong with using it for applications, but it's often overkill for that use case