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

Rust error handling

bitfieldconsulting.com

Post reply on HN
Print view View original

31–40 of 65 posts

Re: Rust error handling

#31

Post by IshKebab »

Buttons840 wrote: post #26
zarathustreal wrote: post #23

Earlier quoted context omitted.

I think you’re misunderstanding the “fail fast!” advice. You want to fail fast in development not in production. In production you want maximum robustness. Users would rather see an error saying “whoopsie, maybe try that again later” than for the program to exit. That’s part of the reason why the functional error handling patterns are becoming so popular these days. They force you to handle errors and give you type-l…

I want my programs to fail fast in production too, because it makes it less likely that even bigger problems will arise. There are many problems that are much worse than a program crashing.

It depends on the program. You don't want your whole web server to crash because of a small error in one route. You probably don't want your CAD program to instantly crash and dump an error to the console because of a divide by zero in the constraints solver.

Though in some cases like that I think it might be appropriate to use `catch_unwind()`.

Re: Rust error handling

#32

Post by edflsafoiewq »

echelon wrote: post #29
edflsafoiewq wrote: post #24

Earlier quoted context omitted.

You can catch panics.

Panics are unexpected and not the preferred mechanism of error handling. Stick to Result .

The GP said

> Users would rather see an error saying “whoopsie, maybe try that again later” than for the program to exit

To achieve this, you need to catch panics. Rust does not use Result for things the OP is talking about like asserts.

Re: Rust error handling

#34

Post by nicce »

edflsafoiewq wrote: post #32
echelon wrote: post #29

Earlier quoted context omitted.

Panics are unexpected and not the preferred mechanism of error handling. Stick to Result .

The GP said > Users would rather see an error saying “whoopsie, maybe try that again later” than for the program to exit To achieve this, you need to catch panics. Rust does not use Result for things the OP is talking about like asserts.

If you want to handle the assert cases, you should not use the asserts in the first place.

Re: Rust error handling

#35

Post by jcranmer »

erik_seaberg wrote: post #30
None4U wrote: post #21

Earlier quoted context omitted.

They tried that in Java and no one uses it...

Lambdas broke checked exceptions. You can't declare that you throw whatever a generic lambda might throw, so they quickly devolved to "I throw nothing (only unchecked)." The "I throw everything" alternative is rarely used because it spreads virally through every caller.

Checked exceptions were vilified long before Java gained lambdas.

Re: Rust error handling

#36

Post by scubbo »

divan wrote: post #5

"Go’s Error Handling Is Perfect, Actually" [1] https://blog.verygoodsoftwarenotvirus.ru/posts/errors-in-go/

This is a very long post to say "Go's Error Handling would be better if it was like Rust's, but the language designers made a mistake early-on and now we don't want to fix it"

Re: Rust error handling

#37

Post by ryandrake »

brigadier132 wrote: post #4

It's far from perfect. One of the biggest problems with Rust error handling is that if you want to have explicit error return types encoded in the type system you need to create ad hoc enums for each method that returns an error. If you only use a single error type for all functions you will inevitably have functions returning Results that contain error variants that the function will never actually return but still…

I'm just now learning Rust, as a long time C++'er, and this was the first part of my Rust journey where I thought to myself, "Boy, this really smells--this couldn't possibly be the idiomatic Rust Way to handle functions that can produce different types of errors. I must be doing something wrong!"

For example, I have a function that takes an array of bytes, decodes it as UTF-8 to text, parses that text into an i32, and checks the int that it is within a valid range. This is not a big function. But it might produce one of: 1. str::Utf8Error, 2. num::ParseIntError, or 3. MyCustomInBoundsError. There's no clean way to write a Rust function that could return either of them. I had to bundle everything up into an enum and then return that, and then the caller has to do some "match" acrobatics to handle each error differently.

I hate to say this, but I miss Python and C++'s exceptions. How nice to just try: something and then:

    except SomeError:
        doFoo()
    except ThatErrror:
        doBar()
    except AnotherError:
        doBaz()
    finally:
        sayGoodbye()
An elegant weapon for a more civilized age.

What do I know though? I'm still in the larval stage of Rust learning where I'm randomly adding &, *, .deref() and .clone() just to try to get the compiler to accept my code.

Re: Rust error handling

#38

Post by baq »

erik_seaberg wrote: post #30
None4U wrote: post #21

Earlier quoted context omitted.

They tried that in Java and no one uses it...

Lambdas broke checked exceptions. You can't declare that you throw whatever a generic lambda might throw, so they quickly devolved to "I throw nothing (only unchecked)." The "I throw everything" alternative is rarely used because it spreads virally through every caller.

Checked exceptions were strongly discouraged because they have nonlocal behavior when changing library code. If you want to rethrow exceptions you can’t handle you have to update all callers when the callee changes the throw signature. Lambdas are orthogonal.

Re: Rust error handling

#39

Post by ryandrake »

IshKebab wrote: post #31
Buttons840 wrote: post #26

Earlier quoted context omitted.

I want my programs to fail fast in production too, because it makes it less likely that even bigger problems will arise. There are many problems that are much worse than a program crashing.

It depends on the program. You don't want your whole web server to crash because of a small error in one route. You probably don't want your CAD program to instantly crash and dump an error to the console because of a divide by zero in the constraints solver. Though in some cases like that I think it might be appropriate to use `catch_unwind()`.

If you're writing something safety critical like avionics flight control software, you probably don't want to crash in production either. I've also always interpreted "fail fast" as "Make defects obvious during development so they don't exist when you deploy to customers."

Re: Rust error handling

#40

Post by edflsafoiewq »

nicce wrote: post #34
edflsafoiewq wrote: post #32

Earlier quoted context omitted.

The GP said > Users would rather see an error saying “whoopsie, maybe try that again later” than for the program to exit To achieve this, you need to catch panics. Rust does not use Result for things the OP is talking about like asserts.

If you want to handle the assert cases, you should not use the asserts in the first place.

That isn't possible. The assert may not even be produced in code you control.

The reason panics/exceptions exist is it is too onerous to handle every possible error condition at all callsites (allocation failure and broken pipes are the famous examples), and it is not possible to enumerate all possible error conditions (unintentional programmer errors for example).

People have religious ideas about handling panics for some reason.

Post reply on HN