3 ms·
You are saying this would not have happened in a C release build where asserts define to nothing? Wonder why these old grey beards chose to go with that.
by stefan_ 11mo ago
You are saying this would not have happened in a C release build where asserts define to nothing?
Wonder why these old grey beards chose to go with that.
- tptacek 11mo agoI am one of those old grey beards (or at least, I got started shipping C code in the 1990s), and I'd leave asserts in prod serverside code given the choice; better that than a totally unpredictable error path.
- ashishb 11mo ago> You are saying this would not have happened in a C release build where asserts define to nothing? Afaik, Go and Java are the only languages that make you pause and explicitly deal with these exceptions.
- tristan-morris 11mo agoAnd rust, but they chose to panic on the error condition. Wild.
- ashishb 11mo ago> And rust, but they chose to panic on the error condition. Wild. unwrap() implicitly panic-ed, right?
- aw1621107 11mo agoI don't think "implicitly panicked" is an accurate description since unwrap()'s entire reason for existing is to panic if you unwrap an error condition. If you use unwrap(), you're explicitly opting into the panicking behavior. I suppose another way to think about it is that Result<T, E> is somewhat analogous to Java's checked exceptions - you can't get the T out unless you say what to do in the case of the E/checked exception. unwrap() in this context is equivalent to wrapping the checked exception in a RuntimeException and throwing that.