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

131–140 of 204 posts

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

#131

Post by Floegipoky »

jiehong wrote: post #73
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…

Would you put the Erlang/Elixir error handling in the "catch Throwable" camp? Because in this case, the error handling is done in a different process altogether (supervisor).

I think of it as "no error handling", the program just crashes. There just happen to be many other programs running, which may restart the program that crashed.

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

#132

Post by heavenlyblue »

im3w1l wrote: post #34
heavenlyblue wrote: post #19

Earlier quoted context omitted.

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

Yeah, it only becomes an issue if you want the compiler to infer that ImpossibleError cannot be raised in while True: pass raise ImpossibleError But normally we are perfectly content to put ImpossibleError in the signature for code like this.

Actually in this specific case you can infer that, and you can have an exhaustive list of language constructs beyond which this becomes undecidable.

There is a practical example of “panic!” in Rust to go around that as well.

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

#133

Post by [deleted] »

ymbeld wrote: post #111
Kaze404 wrote: post #45

Earlier quoted context omitted.

Isn't that what the Result type on Rust is? Sure, one of the branches is still called Error but it's just a plain language construct (a sum type you can write yourself).

The Result type is specifically designed to store value-or-error. One may use it diffently but that’s what it’s made for. The library designers had a choice between making a generic this-or-that type or a value-or-error type and they chose the latter because they thought that that would be the common this-or-that use-case. Even Haskell’s more generic-sounding “Either” type is made for the same purpose: the “right” (a…

[deleted]

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

#134

Post by Floegipoky »

jgilias wrote: post #16

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. So…

I'm imagining a sort of "wax on, wax off" moment but with monads.

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

#135

Post by Ace17 »

golergka wrote: post #87
enriquto wrote: post #33

Earlier quoted context omitted.

> Error handling has been wrong since the beginning 100% this. The very concept of "error" is philosophically unsound. There are no errors; only conditions that you dislike. It is unfortunate that programming languages allow to express your emotional detachment to one of both cases of a branch. Nothing good can come from that. I yearn for a language with no error handling nor exceptions. Just plain language construct…

> There are no errors; only conditions that you dislike. This is true in mathematical sense, but unhelpful in UX sense.

Quite the opposite IMHO : when your program interacts with a user, you cannot panic the program each time something unexpected happens. Here are some examples of unexpected conditions:

- "Null pointer dereference"

- "Out of memory"

- "Disk is full"

- "File does not exist"

- "File does not exist in cache"

- "File exists but is corrupt"

- "Access denied"

- "Connection reset by peer"

It's pretty obvious that all of the above is generally unwanted most of the time.

However, putting them all in the same bag labeled "error", and forcing them to be treated the same way might be counterproductive. Sometimes you might want to panic. Sometimes you might want to retry. Sometimes you might want to ignore!

Now, if your program isn't interactive (such as a compiler), halting on any error might be a choice. But you still have to provide contextualized and accurate error messages, which is easy for the case "File does not exist", and a lot less easy for the case "Out of range index".

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

#136

Post by carapace »

simiones wrote: post #58
enriquto wrote: post #53

Earlier quoted context omitted.

> throw/raise is GOTO. Worse, it's COME FROM! https://en.wikipedia.org/wiki/COMEFROM

To be fair, throw is GOTO. Catch() is COMEFROM :).

Ah, my peeps! I love you guys.

enriquto when you talk about "a language with no error handling nor exceptions" it reminds me of a crazy idea i was toying with: what if you made all "exceptions" require handlers, e.g. what if every divide had to be accompanied by code to deal with divide-by-zero? In other words, DIV(X, Y, Foo) would be (X/Y if Y != 0 else Foo()) And so on...

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

#137

Post by Kaze404 »

ymbeld wrote: post #129
Kaze404 wrote: post #123

Earlier quoted context omitted.

I don't understand what the problem is, in that case. Is it just the fact that it's called an Error instead of something more generic? Not trying to sound dismissive, just trying to understand if there's something I'm missing.

The problem ? You would have to ask the poster that you initially replied to.

Fair enough :)

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

#138

Post by finder83 »

blacktriangle wrote: post #69
enriquto wrote: post #33

Earlier quoted context omitted.

> Error handling has been wrong since the beginning 100% this. The very concept of "error" is philosophically unsound. There are no errors; only conditions that you dislike. It is unfortunate that programming languages allow to express your emotional detachment to one of both cases of a branch. Nothing good can come from that. I yearn for a language with no error handling nor exceptions. Just plain language construct…

Maybe CL got this right with the condition/restart system? In addition to their utility for experimental programming, conditions work really well for handling errors programatically. The general problem seems to be something weird happening far down in the system, for which the correct way forward is dependent on how we got there. This situation can't be handled where the issue happened since that would break encapsu…

I agree, for the actual handling part, I think CL's error system is the best I've seen, and I'm surprised that more languages don't implement a similar system.

It doesn't solve the issue of forcing programmers to handle errors..but then, CL doesn't care a lot about hand holding.

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

#139

Post by dralley »

brazzy wrote: post #96
brundolf wrote: post #86

Earlier quoted context omitted.

It's not perfect, but I think Rust's approach is the best one yet. > Any error system that handles all errors the same way will fail because there are some errors we can ignore, and some errors we must not ignore. Rust has separate categories for these two things. Panics cannot be handled , which pushes the author to use them sparingly. Results must be handled (or explicitly elevated to panics, in a way that's easy t…

>The main weakness of this system, imo, is that the thrower, not the caller, decides whether or not a given error must be handled, and sometimes the answer is "it depends on what the consumer is doing". So... exactly the same problem that Java's checked exceptions have?

Except more ergonomic and less verbose, usually.

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

#140

Post by TacticalCoder »

tus89 wrote: post #126
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…

> Any error system that relies upon developer discipline will fail because errors will be missed. Haven't there been some languages that force functions to return some kind of tuple like: result,error And forces the programmer to at least do: if(error) { } It does not force any kind of correct handling, but simply oversights should be caught. I might be imagining things though.

GP mentionned "maybes". In Haskell (and others) you have for example both maybe and either. When you've got an either you can have either (ah!) the left to indicate an error (and which error) or the right to hold the correct value. And the type system forces you to at deal with both cases (like a maybe forces you to deal with the case where it's "maybe not").
Post reply on HN