Beginner's guide to error handling in Rust

https://www.sheshbabu.com/posts/rust-error-handling/

by rkwz • 4 years ago

150 53 4 years ago

bluejekyll2• 4 years ago

This is a good intro, while it mentions `thiserror`, I personally can’t recommend this enough. For anyone building a library, the ability to wrap underlying errors and generate a From implementation quickly for them (converts from source error to target) is it’s super power. It also takes a simple error string to create the Display implementation. It does all of this and generates code and types that are consistent with the std library.

It’s good to understand the error mechanics, but don’t wast time writing custom errors, just use `thiserror`.

eptcyka• 4 years ago

For years, there have been definitive error crates, each with it's own monstrocity of macro to generate more code, and for every new one there have been painful migrations for codebases of any significant size. Writing out the error types manually isn't actually that difficult.

tempest_• 4 years ago

For library code thiserror has been by far the best experience, sure I can write out the error code manually but why would I waste my time pumping out boiler plate.

The combination of thiserror and anyhow have been my go to for nearly 3 years without issue.

stormbrew• 4 years ago

thiserror is quite a lot lighter than most of the prior ones have been. It also has less magic than they tended to, which is nice. It just does what it says it's gonna do mostly.

Honestly I think thiserror and anyhow strike the right balances that I think they could be candidates for stdlib inclusion, and then might be more optimized.

littlestymaar2• 4 years ago

and for every new one there have been painful migrations for codebases of any significant size

Why did you migrate though? At work, we're still using error_chain for the oldest library we have since the ergonomics of the library isn't an issue for these stable-ish libs. If what you already have works, just don't migrate. It's not like there's likely hidden segfaults or memory vulns waiting there…

burntsushi3• 4 years ago

If you're writing internal libraries or libraries that are otherwise already using proc macros, sure, but I don't otherwise agree with this advice personally. It takes me maybe a couple of extra minutes to write out the error type and associated code. In exchange, every single compilation of my library will be faster as a result.

To be clear, 'thiserror' is great and it would probably fit well inside of std. Then that extra compilation time I'm complaining about could be avoided.

guitarbill• 4 years ago

I don't disagree with this... but is there anything wrong with recommending `thiserror` by default, especially for less experienced Rustaceans? It's fairly sane, encourages "good" error design. I wish there'd been something like it when I started.

And moving forwards, you could a) still write out the error type and associated code to replace `thiserror` fairly easily, or b) possibly benefit from any work being done to speed up proc macros in the future. So I feel like recommending it as a default is still the best option?

lytedev• 4 years ago

Seconded! It also helps in my code that I can see all the things that can go wrong for a given module. Sure, this isn't unique to "thiserror" because you can do this with any enum, but it's much cleaner while being sensible and explicit.

stevefan1999• 4 years ago

The only problem with thiserror is the lack of no_std tho, which leads me to use snafu instead

c7DJTLrn6• 4 years ago

I found error handling in Rust to be an unergonomic nightmare and is one of the reasons I don't want to write it anymore. Usually people recommend crates designed to make the experience better but that's a failure in my opinion. Every project ends up doing it differently -- anything like that should be in the standard library. In Go, you can build massive projects without needing any dependencies to make error handling ergonomic.

ParetoOptimal• 4 years ago

In Go, you can build massive projects without needing any dependencies to make error handling ergonomic.

Because it's always unergonomic?

nindalf2• 4 years ago

I was with you until the end. Go errors leave something to be desired - it’s not easy to wrap, compare errors or print stack trace. These can be fixed with the right library and conventions, but the default error handling is only good enough for small and medium projects. (In my subjective opinion).

Agree that Rust errors need to be better. anyhow and thiserror are fine libraries but I want that experience out of the box, ideally. There are ongoing efforts to improve things, so I’m hopeful.

c7DJTLrn6• 4 years ago

it’s not easy to wrap

  fmt.Errorf("... %w", err)

>compare errors

  errors.Is(err, ErrorType)

lijogdfljk3• 4 years ago

If the bar was as low as Go it would be quite easy in Rust. It's just string concat after all.. but i'm quite glad they didn't use that low bar, it's awful to deal with imo.

c7DJTLrn6• 4 years ago

It's just string concat after all

If you're properly wrapping errors it isn't.

  fmt.Errorf("... %w", err)

throwaway2342322• 4 years ago

Usually people recommend crates designed to make the experience better but that's a failure in my opinion.

I agree, I love Rust, but I'd like to see error handling ergonomics improved.

I'd like to see error handling become more like Zig or Swift.

Until then, I cope with the `anyhow` and `thiserror` crate :|

ReactiveJelly• 4 years ago

I guess I have the Blub effect. Coming from C++ and C#, Rust has my favorite error handling so far.

jcelerier• 4 years ago

In Go, you can build massive projects without needing any dependencies to make error handling ergonomic.

are we talking about the same go where the average code looks like this, a big long chain of if blabla return nil, err ?

https://github.com/cockroachdb/cockroach/blob/5fb4478b94ecaf...

like, code like this is exactly the reason why exceptions were invented

kaba02• 4 years ago

I’m sorry, I honestly can’t take your take seriously if you believe Go’s error handling is remotely ergonomic.

Someone• 4 years ago

FTA: let result = reqwest::blocking::get(url);

  let response = match result {
    Ok(res) => res,
    Err(err) => return Err(err),
  };

Is that truly idiomatic? I would think the Err(err) => return Err(err) line needlessly constructs a copy of result. Or is that necessary because of the borrow checker?

(Also, for those unfamiliar with it: reqwest is not a typo. See https://github.com/seanmonstar/reqwest)

richardwhiuk• 4 years ago

The idiomatic way to write this would be:

let response = reqwest::blocking::get(url)?;

In the way written there's no additional copy.

Ambroisie• 4 years ago

As pointed out, the idiomatic way to do this is to use the try operator (`?`).

But to answer your question about copies : Rust is a move-only language, copies are actually called `.clone()`, except for a few types which are cheap enough to copy that they implement the `Copy` trait.

So in the code you quoted, the match is done on the value of `result` (notice that there is not borrowing/`&` operator). The match arm `Err(err)` moves `err` out of `result` and returns it. Obviously, the compiler will optimize away all those moves, it's as if they did not exist.

littlestymaar2• 4 years ago

But to answer your question about copies : Rust is a move-only language, copies are actually called `.clone()`, except for a few types which are cheap enough to copy that they implement the `Copy` trait.

This is almost true, but not exact. Copy is for everything where cloning is just memcopy, that doesn't means it's necessarily cheap ([42;4_000_000] implements Copy, yet it's not cheap to copy at all…).

And moving things sometimes (but not always) means the thing is getting memcopied (or it could use a pointer, depending on the optimizer's m̶o̶o̶d̶ euristics)

throwaway2342322• 4 years ago

I would think the Err(err) => return Err(err) line needlessly constructs a copy of result

It sounds like this is coming from a C++ bias? So please forgive me if this is wrong.

Rust, in my experience, favors move semantics first, then copy semantics after.

I know in C++, we had implicit copy constructors, with move semantics after with rvalue references, where you need to use `std::move` in a lot of cases.

So what helps, in my opinion, is to think of Rust as using `std::move` as a default.

saghm• 4 years ago

So what helps, in my opinion, is to think of Rust as using `std::move` as a default

Even more than that, with the exception of types that implement `Copy` (e.g. bools, integers, etc.), using after a move won't just silently degrade to a copy, but will cause a compiler error. Copying is required to be explicit for all but the most trivial types.

masklinn• 4 years ago

Or is that necessary because of the borrow checker?

It’s not because of the borrow checker, it’s because Rust defaults to (destructive) moves, and implicit copies can only be trivial.

Any non-trivial copy has to go through an explicit clone() instead.

jcranmer• 4 years ago

I would think the Err(err) => return Err(err) line needlessly constructs a copy of result.

You would think wrong. In Rust, everything is move by default. To create a copy, you need to explicitly call .clone() on an object (assuming it implements Clone, of course), or you can implement Copy for the type, which will cause .clone() to be called instead of moving the value.

(I'm not actually sure where the compiler will generate calls to clone() on Copy types in favor of moving. In practice, you're not going to implement Copy for a type that isn't trivially copyable anyways [using the C++ definition], so any optimizer would easily be able to elide any excessive copy operations.)

joaonmatos• 4 years ago

Copy types must be trivially copiable bitwise (the clone implementation is returning the deref of the cloned type), so a copy is a move except for the fact that the previous reference is not invalidated.

The docs for the trait (core::marker::Copy) are pretty good

PointyFluff• 4 years ago

OJFord2• 4 years ago

Why isn't `Result<T, E>` just `Result<T, E> where E: std::Error`?

I love rust, but I hate 'no from<lib::Error> implementation for my::Error' et al. 99.99% of the time I just want to bubble up a string to print from anything I'm using that might error.

I've used anyhow and friends, it just still requires more from me than I think should necessary.

But this is an honest question, several people put more thought into it than I have and decided it should be so, why?

steveklabnik2• 4 years ago

One good reason to not do this is it's std::error::Error, but there is no corresponding core::error::Error. no_std needs to be able to use Result too.

OJFord2• 4 years ago

That feels a bit incomplete to me - that explains the language mechanism existing for using something different, but not std's lack of something more specific?

As in, std::result could use std::error::Error to specialise core::result's more generic Result?

And it's barely any extra work at all for a maintainer of a crate with a `no_std` feature, since you can still use the same Result; it's no longer required that its Error type implements std's, but it can?

kccqzy• 4 years ago

There are plenty of cases where the Err alternatives of Result doesn't actually represent an error, just a case to be handled differently. For example the binary search function (https://doc.rust-lang.org/std/primitive.slice.html#method.bi...) returns an index of the insertion position when the search fails. That's not usually an error to be surfaced.

I find that this distinction is basically the application vs library distinction in the article. Application developers tend to "just want to bubble up a string" whereas library developers tend not to.

woodruffw• 4 years ago

This is a good reason (for the purposes of stability), but IMO a misuse of `Result` in the standard library. It really ought to be something custom, closer perhaps to `ControlFlow`[1] (which is newer). But even that's not a great fit.

[1] https://doc.rust-lang.org/std/ops/enum.ControlFlow.html

sbt• 4 years ago

The problem with errors in Rust is that the stdlib defined Error as a trait and traits are hard to use (not sized, etc). The current state of affairs with thiserror and anyhow is not satisfactory if we want to ease the Rust learning curve.

Errors are too fundamental to be this hard.

kaba02• 4 years ago

I’m not sure there is a way out - this is the fundamental aspect of low level languages. If you want to care about memory allocation, you have to care about it everywhere.

Rust is a really great language, but I believe it is a trap to go down this “high-level low-level language” route C++ also chose.

Beginner's guide to error handling in Rust

Related Stories