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.

[–] jenesaisquoi@feddit.org 3 points 1 day ago* (last edited 1 day ago) (1 children)

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

[–] treadful@lemmy.zip 2 points 20 hours ago (1 children)

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.

[–] jenesaisquoi@feddit.org 2 points 3 hours ago (1 children)

For multiple types turning into one variant: you can either impl From for the others yourself, or you can have another enum with variants for them and have thiserror generate the From impl. I usually have lots of enums, at least one per module, sometimes even one per function, that form a tree. The errors you design should relate to the action that was being tried, and only encapsulate the lower error as context information.

I see you're using strings. You can do that, but then you'll lose control over formatting, and additional context info that might be contained in them.

Designing errors isn't trivial and requires some experience. Try some things and over time you'll see what works best.

You can also check out https://docs.rs/snafu/latest/snafu/guide/index.html, another great library - their docs contain excellent guidance on designing error types.

[–] treadful@lemmy.zip 1 points 7 minutes ago

I see you’re using strings. You can do that, but then you’ll lose control over formatting, and additional context info that might be contained in them.

I just haven't figured out how to jam multiple error types into one enum variant yet. There's no reason for the consumer of the module to get more pointless variants, so I'm not really sure I want an enum of enums, but maybe I'm overthinking it. I'll fiddle more and check out your link later today.

[–] KindaABigDyl@programming.dev 9 points 2 days ago

I think this is more idiomatic:

let result = foo(a, b)
    .map_err(|e| MyErrorEnum::Error(e.to_string()));

[–] gabmus@retrolemmy.com 14 points 2 days ago* (last edited 2 days ago) (1 children)

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

[–] treadful@lemmy.zip 4 points 2 days ago (2 children)

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.

[–] gabmus@retrolemmy.com 5 points 2 days ago

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)

[–] ISO@lemmy.zip 3 points 2 days ago (1 children)

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

[–] treadful@lemmy.zip 1 points 1 day ago (1 children)

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.

[–] jerkface@lemmy.ca 0 points 1 day ago* (last edited 1 day ago) (1 children)

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.

[–] treadful@lemmy.zip 1 points 1 day ago

It's not about "sheer joy", nor obfuscation. It's about making code easier to write and easier to grok.

[–] Gobbel2000@programming.dev 3 points 2 days ago (1 children)

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.

[–] treadful@lemmy.zip 1 points 1 day ago

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.

[–] calcopiritus@lemmy.world 0 points 2 days ago (1 children)

That's what ? is for. If you have to do that manually, something is not working correctly.

[–] treadful@lemmy.zip 1 points 1 day ago (1 children)

That only works if everything has the same error types.

[–] calcopiritus@lemmy.world 4 points 1 day ago (1 children)

Or just implement Into for your error type. ? Works for Into

[–] jenesaisquoi@feddit.org 2 points 1 day ago

Don't implement Into, instead, implement From - and you'll get Into for free