4 ms·
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 ap
by 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 agoGlad 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.