Earlier quoted context omitted.
Like your comment? j/k :) I'm using this incident to draw attention to Rust's panic behavior. Rust could use additional language features to help us write mostly panic-free* code and statically catch even transitive dependencies that might subject us to unnecessary panics. We've been talking about it on our team and to other Rust folks, and I think it's worth building a proposal around. Rust should have a way to stat…
It's already in the box... there's a bunch of options from unwrap_or, etc... to actually checking the error result and dealing with it cleanly... that's not what happened. Not to mention the possibility of just bumping up through Result chaining with an app specific error model. The author chose neither... likely because they want the app to crash/reload from an external service. This is often the best approach to an…
The engineers had more semantic tools at their disposal for this than a bare `unwrap()`.
This was a systems failure. A better set of tools in Rust would have helped mitigate some of the blow.
`unwrap()` is from pre-1.0 Rust, before many of the type system-enabled error safety features existed. And certainly before many of the idiomatic syntactic sugars were put into place.
I posted in another thread that Rust should grow annotation features to allow us to statically rid or minimize our codebase of panic behavior. Outside of malloc failures, we should be able to constrain or rid large classes of them with something like this:
panic fn my_panicky_function() {
None.unwrap(); // NB: `unwrap()` is also marked `panic` in stdlib
}
fn my_safe_function() {
// with a certain compiler or Crates flag, this would fail to compile
// as my_safe_function isn't annotated as `panic`
my_panicky_function()
}
In any case, until something is done, this is not the last time we'll hear unwrap() horror stories.