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

21–30 of 65 posts

Re: Rust error handling

#21

Post by None4U »

brigadier132 wrote: post #18
lilyball wrote: post #16

Earlier quoted context omitted.

This is true, though the issue of having error variants the function can't return is fairly overblown, because most code doesn't bother handling all error variants individually. Most of the time an error is either propagated upwards (possibly wrapped in another error) or logged. Inspecting the error variants is usually only done if you want to specially handle some of them (such as handling `ErrorKind::NotFound` when…

We can disagree on it being overblown or not but I think it would be enormously useful to be able to look at a function signature and know exactly how it can fail.

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

Re: Rust error handling

#22

Post by Buttons840 »

danenania wrote: post #13
Buttons840 wrote: post #6

Earlier quoted context omitted.

> Spend any amount of time in programming circles, and just as the sun rises and falls, you are certain to hear someone complain about error handling in Go. These complaints are, anecdotally, rarely well thought out suggestions on what error handling could or should be like in a language like Go, but often merely boil down to “I don’t like having to look at it”. I read it. The first paragraph dismisses preferences in…

Personally I find it much faster to pinpoint errors in the Go style. With a stack trace, I have to cross-reference with code (ensuring versions match) and filter out a bunch of irrelevant calls in the stack. It’s not uncommon for the stack trace to end deep in library code with the root cause being many calls removed, making me check through a bunch of call sites to figure out what happened. In Go if good context is…

Adding good context is also possible with exceptions.

I think people often compare good Go code with, say, bad Python code where every good practice has been ignored. Go is new and people who write Go are more likely to be skilled and enthusiastic about its design philosophy, so it is somewhat true that Go code is more likely to be high quality.

There's nothing Go error handling does that cannot be done with exceptions. When it comes to bad code, bad Go code is likely to ignore errors or have no context, whereas bad Python code is less likely to ignore errors and at least a raw stacktrace has some context.

This is an argument as old as time though.

Re: Rust error handling

#23

Post by zarathustreal »

_nalply wrote: post #14

> But, since good programs don’t panic, and neither do good programmers, it’s very rare that using unwrap or expect is actually the right thing to do. I respectfully disagree. The assert!() macro is a way to document invariants. It's a bug if a variant is violated. It shouldn't have happened, but if it happens, then there's nothing the user can do except reporting the crash. The unwrap() and expect() method document…

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-level info about how the program can fail.

Re: Rust error handling

#24

Post by edflsafoiewq »

zarathustreal wrote: post #23
_nalply wrote: post #14

> But, since good programs don’t panic, and neither do good programmers, it’s very rare that using unwrap or expect is actually the right thing to do. I respectfully disagree. The assert!() macro is a way to document invariants. It's a bug if a variant is violated. It shouldn't have happened, but if it happens, then there's nothing the user can do except reporting the crash. The unwrap() and expect() method document…

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…

You can catch panics.

Re: Rust error handling

#25

Post by lilyball »

brigadier132 wrote: post #18
lilyball wrote: post #16

Earlier quoted context omitted.

This is true, though the issue of having error variants the function can't return is fairly overblown, because most code doesn't bother handling all error variants individually. Most of the time an error is either propagated upwards (possibly wrapped in another error) or logged. Inspecting the error variants is usually only done if you want to specially handle some of them (such as handling `ErrorKind::NotFound` when…

We can disagree on it being overblown or not but I think it would be enormously useful to be able to look at a function signature and know exactly how it can fail.

The ways in which a function can fail is typically the job of the documentation.

Re: Rust error handling

#26

Post by Buttons840 »

zarathustreal wrote: post #23
_nalply wrote: post #14

> But, since good programs don’t panic, and neither do good programmers, it’s very rare that using unwrap or expect is actually the right thing to do. I respectfully disagree. The assert!() macro is a way to document invariants. It's a bug if a variant is violated. It shouldn't have happened, but if it happens, then there's nothing the user can do except reporting the crash. The unwrap() and expect() method document…

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.

Re: Rust error handling

#27

Post by [deleted] »

zarathustreal wrote: post #23
_nalply wrote: post #14

> But, since good programs don’t panic, and neither do good programmers, it’s very rare that using unwrap or expect is actually the right thing to do. I respectfully disagree. The assert!() macro is a way to document invariants. It's a bug if a variant is violated. It shouldn't have happened, but if it happens, then there's nothing the user can do except reporting the crash. The unwrap() and expect() method document…

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…

[deleted]

Re: Rust error handling

#28

Post by steveklabnik »

spoiler wrote: post #15
pjmlp wrote: post #11

Except for anything more production quality, one needs to lean on third party crates to compose errors without explicitly write tons of boilerplate composing result types. Something that should be supported directly.

I agree that it's not ideal, but using something like anyhow/l and thiserror honestly doesn't feel _that_ bad. > Something that should be supported directly. Rust has "adapted" some crates into stdlib in the past. Are there any efforts to that for error handling?

We're on the like, third (fourth?) generation of error handling crates, and while there's some degree of consensus happening, I'm not sure that it's time for it yet.

If Rust had adopted error_chain into the stdlib, that would have been a huge mistake.

Re: Rust error handling

#29

Post by echelon »

edflsafoiewq wrote: post #24
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…

You can catch panics.

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

Stick to Result.

Re: Rust error handling

#30

Post by erik_seaberg »

None4U wrote: post #21
brigadier132 wrote: post #18

Earlier quoted context omitted.

We can disagree on it being overblown or not but I think it would be enormously useful to be able to look at a function signature and know exactly how it can fail.

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.
Post reply on HN