4 ms·

tl;dr: Author convincingly argues that Rust `unwrap()` (Java `Optional.get`, Haskell `fromJust`) is fine when you either have checked that the call will not fai

tl;dr: Author convincingly argues that Rust `unwrap()` (Java `Optional.get`, Haskell `fromJust`) is fine when you either have checked that the call will not fail, or when you're in a unit test or similar where a panic is a helpful result. (And, conversely, that it's not fine to use it to avoid doing real error handling)

OJFord 4y ago
Buried in your 'or similar' is the more controversial and helpful (IMO) use - the infamous 'this should never happen' exceptions.
- marcosdumay 4y ago
  Well, if you want a definitive answer, it's "it depends". Those errors are not all alike.
- burntsushi 4y ago
  No, that isn't buried in the "or similar" of the GP. They mention that explicitly with "checked that the call will not fail." The "or similar" refers to documentation examples and prototyping/one-off scripts.
drexlspivey 4y ago
Is this supposed to be controversial? Even rust docs say so https://doc.rust-lang.org/book/ch09-03-to-panic-or-not-to-panic.html#cases-in-which-you-have-more-information-than-the-compiler https://doc.rust-lang.org/book/ch09-03-to-panic-or-not-to-pa...
- burntsushi 4y ago
  Nope. But people are thoroughly confused by it. Comes up all of the time. And a lot of people have more extremist positions. Banning unwrap. Or banning any panicking branches at all. That's why my blog post covers an example where we convert a function that never panics (sensible) to a function whose signature says it might return an error, but it actually will never return an error (bonkers). People advocate for this. After publishing this article, it almost seems like people are more confused than I thought. Idk. Anyway, no, this blog is not meant to be controversial. It is meant to untangle knots.
  - wokwokwok 4y ago
    Maybe people didn’t read all the way to the end of your article? I mean, my gut feel response was to the first half was, this is crazy talk. Look, given an api that when I call it, it either a) panics or b) returns an error, I’m pretty clear on which one I prefer in general. …but the point (or what I got out of it anyway, by the end) isn't “It’s fine to panic”. It’s not fine to panic arbitrarily. Code should not panic generally speaking. …but there are also times when it a unavoidable, or pointlessly pedantic (eg. Slice index, FSM example) to avoid it completely. I certainly started reading the top section (aka “Therefore, when runtime invariants arise…”) and my response was: yes, but most of the time you don’t have those. …and if you don’t, why would you use unwrap? I can say, at least, you made me have a good think about it.
    - burntsushi 4y ago
      Glad you got a good think. One thing worth pointing out, is that I did try to head off an experience like what you had by stating my position up front. In the first section after the ToC, the third bullet point reads: > If a Rust program panics, then it signals a bug in the program. That is, correct Rust programs don’t panic. I suspect you might have just accidentally skipped over that. Because I think it re-affirms that you should indeed not panic arbitrarily. As for runtime invariants, I have them a lot in Rust. I tend to work on lower level text primitives (regex engines) where perf is quite important. Perf tends to add complexity in the form of an increased number of runtime invariants. I do my best to push them to compile time where I can, but it just isn't always possible.

OJFord 4y ago

Buried in your 'or similar' is the more controversial and helpful (IMO) use - the infamous 'this should never happen' exceptions.

marcosdumay 4y ago
Well, if you want a definitive answer, it's "it depends". Those errors are not all alike.
burntsushi 4y ago
No, that isn't buried in the "or similar" of the GP. They mention that explicitly with "checked that the call will not fail." The "or similar" refers to documentation examples and prototyping/one-off scripts.

drexlspivey 4y ago

Is this supposed to be controversial? Even rust docs say so https://doc.rust-lang.org/book/ch09-03-to-panic-or-not-to-panic.html#cases-in-which-you-have-more-information-than-the-compiler https://doc.rust-lang.org/book/ch09-03-to-panic-or-not-to-pa...

burntsushi 4y ago
Nope. But people are thoroughly confused by it. Comes up all of the time. And a lot of people have more extremist positions. Banning unwrap. Or banning any panicking branches at all. That's why my blog post covers an example where we convert a function that never panics (sensible) to a function whose signature says it might return an error, but it actually will never return an error (bonkers). People advocate for this. After publishing this article, it almost seems like people are more confused than I thought. Idk. Anyway, no, this blog is not meant to be controversial. It is meant to untangle knots.
- wokwokwok 4y ago
  Maybe people didn’t read all the way to the end of your article? I mean, my gut feel response was to the first half was, this is crazy talk. Look, given an api that when I call it, it either a) panics or b) returns an error, I’m pretty clear on which one I prefer in general. …but the point (or what I got out of it anyway, by the end) isn't “It’s fine to panic”. It’s not fine to panic arbitrarily. Code should not panic generally speaking. …but there are also times when it a unavoidable, or pointlessly pedantic (eg. Slice index, FSM example) to avoid it completely. I certainly started reading the top section (aka “Therefore, when runtime invariants arise…”) and my response was: yes, but most of the time you don’t have those. …and if you don’t, why would you use unwrap? I can say, at least, you made me have a good think about it.
  - burntsushi 4y ago
    Glad you got a good think. One thing worth pointing out, is that I did try to head off an experience like what you had by stating my position up front. In the first section after the ToC, the third bullet point reads: > If a Rust program panics, then it signals a bug in the program. That is, correct Rust programs don’t panic. I suspect you might have just accidentally skipped over that. Because I think it re-affirms that you should indeed not panic arbitrarily. As for runtime invariants, I have them a lot in Rust. I tend to work on lower level text primitives (regex engines) where perf is quite important. Perf tends to add complexity in the form of an increased number of runtime invariants. I do my best to push them to compile time where I can, but it just isn't always possible.