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

11–20 of 204 posts

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

#11

Post by seeekr »

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…

Couldn't this "inverse if let" be provided with a simple macro? Is that where you encountered bugs in the borrow checker?

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

#12

Post by EugeneOZ »

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…

Try methods "is_err", "is_ok"; or for Option: "is_some", "is_none".

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

#13

Post by jimis »

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.

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

#14

Post by Veserv »

The author appears to be trying to use error messages in their own code to debug it which is a pretty weird way to use error messages. Error messages are for humans and users. If you are developing your own code you can just use a debugger to debug the problem.

Assuming they only had access to basic tools they could have just plopped down a breakpoint in the relevant error return from copy_from_process() and slowly walk up to discover their nullptr error pretty quickly without any code changes. If they had modern tools they could have just turned on tracing and then run backwards to figure that out and where the nullptr came from.

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

#15

Post by chmod775 »

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…

> Error handling has been wrong since the beginning, and has continued to be wrong ever since.

Maybe it's not error-handling that is the problem then, but undisciplined software developers writing bad code?

Out of all the engineering disciplines, us software engineers have to be the worst bunch by far.

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

#16

Post by jgilias »

The rule of thumb for me is `thiserror` for libraries, `anyhow` for executables. Seems to work well enough in the vast majority of cases. I do agree that the Rust way can be frustrating at first. But then, at some point it becomes clear that being forced to keep your error conditions in mind at all times is actually a healthy thing. Then going back to languages where code may fail anywhere seems less than optimal. Sort of like the difference between securing your ropes and just crossing fingers.

As a side note, I've found that getting used to `Result` actually gives an added benefit of getting comfortable with the idea of such computational contexts in general. Be it Options, Maybes, Futures, Promises, Haskell IO, or anything of that kind.

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

#17

Post by nullc »

Someday I will attempt to use some rust software from the internet without almost immediately running into a panic with some inscrutable message.

Maybe that day will be a day after _f$#$@@#$_ _crashing_ stops being the easiest and most idiomatic way of handling unexpected conditions.

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

#18

Post by duckerude »

EugeneOZ wrote: post #12
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…

Try methods "is_err", "is_ok"; or for Option: "is_some", "is_none".

That's not great if you still want to use the underlying value, because then you need to unwrap it later.

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

#19

Post by heavenlyblue »

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…

> Attempting to get the complete set of error types that any given call may raise is a fool's errand because of the halting problem it eventually invokes.

That’s not true.

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

#20

Post by why_Mr_Anderson »

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…

Because all systems try to handle several kinds of unexpected behavior in the exactly the same way - invalid arguments (e.g. 'x == null') - code logic (e.g. 'if (x.salary I'd argue that only the 3rd kind is actually 'exception', it's completely out of program's control.

Code contracts are wonderful way of dealing with 1st and 2nd kind, sadly they didn't catch up and remains mostly unknown. They are vastly superior to tests and also serve as much better way to document intent of the code, how the author expected the code to work.

Post reply on HN