Welcome to the Rust community! This is a place to discuss about the Rust programming language.
Credits
catch_unwind[...] does not guarantee the program is in a consistent state afterward, since Drop impls may have run partway through.
Wait, what? Any more details about this, I've never heard about that before. Partially run Drop impls sounds like a big potential for undefined behavior, how could catch_unwind possibly cause that?
EDIT: The more I read this article, the more AI-generated it looks and so I'm sort of wondering if the above quote is just complete bogus.
Rust's explicitness and being forced to handle every case is so incredibly frustrating but also feels so right.
Thanks for posting this. I'm still trying to figure out the best technique to error handling in my programs. I just learned about anyhow the other day and kind of starting to work that in.
I'm so tired of having to reshape errors with match statements.
let result = match foo(a, b) {
Ok(r) => r,
Err(err) => {
return Err(MyErrorEnum::Error(err.to_string()));
}
};
This pattern is an annoying habit I keep finding myself repeating.
Check out https://docs.rs/thiserror/latest/thiserror/. You can do this:
#[derive(Debug, thiserror::Error)]
pub enum MyError {
#[error("Failed to do the thing, blabla, put something clear here")]
DoingTheThing(#[from] LibraryError)
}
And then you can just do foo(a, b)? because there's now a From impl for MyError from LibraryError.
You now get a proper error chain via source(). You can use this to have a nice report at the top level using https://docs.rs/thiserror-ext/0.3.0/thiserror_ext/struct.Report.html that looks like this:
Outer error text
Caused by these errors (recent errors listed first):
1. Middle error text
2. Inner error text
I'm playing with this pattern, but it seems like it forces you to have a variant for every upstream error. For instance, I have this DatabaseError:
#[derive(Clone, Debug, Error)]
pub enum DatabaseError {
#[error("database error: {0}")]
Database(String),
#[error("failed to deserialize from DB: {0}")]
Deserialize(String),
#[error("failed to serialize input: {0}")]
Serialize(String),
#[error("unexpected error: {0}")]
Unexpected(String),
}
But I might have 2 or 3 error types that turn into DatabaseError::Serialize. Then I end up doing custom From impls. Then I realize serde might be Serialize or Deserialize, so I'm back where I started.
Though I would like to have that chain of errors, but I haven't figured out how to do the custom impl From yet (or if it ends up being useful in my case, even).
Thanks for the ideas.
I think this is more idiomatic:
let result = foo(a, b)
.map_err(|e| MyErrorEnum::Error(e.to_string()));
Depending on a usecase you might find that many of your "entrypoint functions" might all share the same error type. For example, if you're making an API backend it's likely gonna be something a status code and a message.
In that case a simple way to avoid having to pattern match every single error is to implement From<DownstreamErrorType> for MyErrorEnum, and just use the ? operator. Example:
fn do_something_with_database() -> Result<Whatever, DatabaseError> { /* ... */ }
impl From<DatabaseError> for MyErrorType { /* ... */ }
// this would be your function
fn api_get_something() -> Result<SomeOtherType, MyErrorType> {
let data: Whatever = do_something_with_database()?;
// ...
Ok(/* ... */)
}
EDIT: this is mentioned in the article already
It's a little verbose (like most of Rust), but I really like this approach. It'll make a lot of logic easier to reason about. I missed that in the article, so thanks for pointing it out.
Well, is it really? The verbose part is converting from an error type to another, which you would likely also do in a language with exceptions in the catch block, or in some giant cursed interceptor thing that does a switch/match on the error type (something I had the displeasure to witness with my own two eyes, multiple times)
(Didn't read the article.)
It's not a secret approach or anything. thiserror gives you that with a simple #[from] attribute annotation on the relevant error variant on your Error enum (which is what your Error type should be).
In your case, this just works because you're not attaching custom context to your error. Usually, you would want to attach some context, and in that case, .map_err()would obviously still be needed, and that's fine. This idea of having to write as little code as possible is stupid.
Sometimes, attaching context once is sufficient, sometimes it's not. If it's the former, then you can still do From in your bigger error enums which have variants from your smaller error enums (e.g. crate-level Error type with variants trivially wrapping module-level Error types).
This idea of having to write as little code as possible is stupid.
Is it? Not only is it less work, but generally makes the code way easier to reason about. In this case, instead of just seeing simple function calls explaining the logic flow, you visually have to parse all this weird extra cruft that is generally irrelevant to what the block is doing.
Yes, code golf practiced for any reason other than the sheer joy of it is "stupid." It especially doesn't belong in production code. If typing is really so bad, there are any number of local agents that are competent to finish that map fragment for you.
It's not about "sheer joy", nor obfuscation. It's about making code easier to write and easier to grok.
There is the map_err method on Result which simplifies this case. But yes, anyhow is still easier if you don't care that much about the error contents.
Completely forgot about this one. Think I still like the other approach (implementing From) for most places, but I'll keep this one in mind too, thanks.
That's what ? is for. If you have to do that manually, something is not working correctly.
That only works if everything has the same error types.
Or just implement Into for your error type. ? Works for Into
Don't implement Into, instead, implement From - and you'll get Into for free