Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Where Everything Went Wrong: Error Handling and Error Messages in Rust (2020)

msirringhaus.github.io

Post reply on HN
Print view View original

21–30 of 204 posts

Re: Where Everything Went Wrong: Error Handling and Error Messages in Rust (2020)

#21

Post by nivenkos »

jimis wrote: post #13

I find this article hard to read. But I believe its point stands. In Rust: - You bubble up errors using `?` operator, - then you get a nice error message. - However the location of the error is lost, the more complex the program, the harder it is to figure out where "permission denied" for example comes from.

You can attach context to the errors though.

It's only really a pain when writing libraries as you have to be so specific about your error types, etc.

Overall, it's probably still the "least bad" option compared to other languages' approaches (both Go and Python are painful for this for example). But it can be a lot of extra work sometimes, especially when just working on the first basics of a library crate.

Re: Where Everything Went Wrong: Error Handling and Error Messages in Rust (2020)

#23

Post by simiones »

mhh__ wrote: post #9
kstenerud wrote: post #4

Error handling has been wrong since the beginning, and has continued to be wrong ever since. First, we had error codes. Except these were wrong because people forget all the time to check them. Then we had exceptions, which solved the problem of people forgetting to check by crashing the app. Then the Java team got the bright idea to have checked exceptions, which at first helped to mitigate crashes from uncaught exc…

The only system I think should completely go is Exceptions except in the case of termination or absolutely catastrophic failure - this isn't really about programming but rather that the implementation is a total pain, the compiler struggles to optimize them, and even better they make quite a few safety analyses like borrow checking very difficult because the control flow graph basically explodes when you start consid…

In terms of control flow, this:

  try {
    someCall();
  } catch (ErrorICanHandle err) {
    //handle
  }
perfectly equivalent to this:

  err = someCall();
  if canHandle(err) {
    //do something
  } else {
    return err
  }
I don't see why so many people think exceptions make code harder to analyze. In my opinion, it is errors themselves that make code hard to analyze, regardless of implementation strategy.

The only difference between exceptions and error returns/error codes is in human readability: one makes the bubbling behavior explicit, which clutters the code but makes it obvious; the other makes the bubbling behavior implicit, which keeps the code cleaner, but also less obvious.

After writing professionally in both languages with Exceptions (Java/C#/Python) and in Go, I much prefer Exceptions to error values/codes, but I can appreciate that it may be different in other domains or for other people.

Re: Where Everything Went Wrong: Error Handling and Error Messages in Rust (2020)

#24

Post by tiddles »

Subsentient wrote: post #8

For the mostpart, Rust error handling is okay. What really rustles my jimmies, however, is the often mandatory indentation because of a lack of an inverse "if let". I prefer to bail out of a block if a condition is NOT met, rather than execute another nested block if it IS met. Rust makes that harder than it should be. It's good code hygiene in every other language, and Rust makes it painful in places. I've even been…

The most common time this comes up for me is trying to use continue/break if a value is None/Err :

  loop {
    let thing = match foo() {
      Some(bar) => bar,
      None => continue,
    }
  }
Yet I still always first try to put the continue in an unwrap_or_else first..

Re: Where Everything Went Wrong: Error Handling and Error Messages in Rust (2020)

#25

Post by conradludgate »

Subsentient wrote: post #8

For the mostpart, Rust error handling is okay. What really rustles my jimmies, however, is the often mandatory indentation because of a lack of an inverse "if let". I prefer to bail out of a block if a condition is NOT met, rather than execute another nested block if it IS met. Rust makes that harder than it should be. It's good code hygiene in every other language, and Rust makes it painful in places. I've even been…

You can do something like that

``` let x = Some(1); let x = match x { Some(x) => x, None => return, };

assert_eq!(x, 1); ```

Re: Where Everything Went Wrong: Error Handling and Error Messages in Rust (2020)

#26

Post by magicalhippo »

nivenkos wrote: post #21
jimis wrote: post #13

I find this article hard to read. But I believe its point stands. In Rust: - You bubble up errors using `?` operator, - then you get a nice error message. - However the location of the error is lost, the more complex the program, the harder it is to figure out where "permission denied" for example comes from.

You can attach context to the errors though. It's only really a pain when writing libraries as you have to be so specific about your error types, etc. Overall, it's probably still the "least bad" option compared to other languages' approaches (both Go and Python are painful for this for example). But it can be a lot of extra work sometimes, especially when just working on the first basics of a library crate.

> You can attach context to the errors though.

I'd say you should attach context.

If there's problems accessing a file, then having an error message without the filename in it is near useless.

Re: Where Everything Went Wrong: Error Handling and Error Messages in Rust (2020)

#27

Post by conradludgate »

the_mitsuhiko wrote: post #22

At this point I'm quite happy with error handling in Rust. I just wish the backtrace member on the error trait was not nightly only and we had the ability to attach backtraces to errors.

I'm pretty sure eyre[0] can provide backtraces in stable using `stable-eyre`

[0]: https://docs.rs/eyre/0.6.5/eyre/

Re: Where Everything Went Wrong: Error Handling and Error Messages in Rust (2020)

#28

Post by skinkestek »

mhh__ wrote: post #9
kstenerud wrote: post #4

Error handling has been wrong since the beginning, and has continued to be wrong ever since. First, we had error codes. Except these were wrong because people forget all the time to check them. Then we had exceptions, which solved the problem of people forgetting to check by crashing the app. Then the Java team got the bright idea to have checked exceptions, which at first helped to mitigate crashes from uncaught exc…

The only system I think should completely go is Exceptions except in the case of termination or absolutely catastrophic failure - this isn't really about programming but rather that the implementation is a total pain, the compiler struggles to optimize them, and even better they make quite a few safety analyses like borrow checking very difficult because the control flow graph basically explodes when you start consid…

> the compiler struggles to optimize them,

Nitpick: I'd say if you need the compiler to optimize exception handling you are using them wrong.

Exceptions are for exceptional circumstances.

(if you mean that exceptions mess up optimization of surrounding code that could be a bigger deal but I won't accept that without pointers to benchmarks$

Re: Where Everything Went Wrong: Error Handling and Error Messages in Rust (2020)

#29

Post by tiddles »

the_mitsuhiko wrote: post #22

At this point I'm quite happy with error handling in Rust. I just wish the backtrace member on the error trait was not nightly only and we had the ability to attach backtraces to errors.

I've migrated a few big projects through several iterations of different error handling crates, which was always painful. For now I've settled on thiserror, but only until backtraces are stable - then it's back to the churn :)

Re: Where Everything Went Wrong: Error Handling and Error Messages in Rust (2020)

#30

Post by nwellnhof »

rklaehn wrote: post #3
jstrong wrote: post #2

as someone who works 95% of the time in rust, how to handle my errors is never a problem for me. I think the issue is the expectations of people coming into it with a different frame of reference, expecting the kind of traceback/exception framework built in - and for that to be a typical debugging workflow. like 95 times out of 100, I just `.map_err(|e| /* code to convert e to return type's error... */)` and I'm done…

Rust error handling is great for reliable systems. But it used to be really annoying when just doing exploratory coding. With the anyhow crate, this problem is solved as well. Just use anyhow if you just want to try something out quickly without being slowed down by error type mismatches, and then later refine it to a handcrafted error type. I prefer rust error handling over all other languages I worked with (scala,…

> Rust error handling is great for reliable systems.

Last time I checked, Rust couldn't even catch malloc failures.

Post reply on HN