

Don't Panic: The Hitchhiker's Guide to Unwinding - steveklabnik
http://lucumr.pocoo.org/2014/10/30/dont-panic/

======
kibwen
Unwinding-by-default is perhaps the last contentious Rust feature that's still
on the table. I'm glad that Armin's giving it the coverage it deserves, but
there's a little more to the story here both for and against the notion of
unwinding.

 _For_ : for some domains, you really, really, really want to be able to
handle panics. For a notable example, one of the first production deployments
of Rust is a Ruby gem that runs inside of a client's Rails process
([https://www.skylight.io/](https://www.skylight.io/)). Without the ability to
unwind, a panic in your Rust code would bring down the whole process
(henceforth an "abort"), and your paying customers will probably be somewhat
peeved. Servo is also looking to leverage unwinding, so that a panic in one
tab doesn't abort the entire browser process.

 _Against_ : the concept of unwinding is inherently flawed in some very
pernicious ways. Say you're the user in the previous paragraph who _needs_ to
catch panics. You have everything set up properly, and when your code panics
you're prepared: the stack unwinds, freeing resources and calling destructors.
Everything is peachy. But here's a twist: while unwinding, what happens if one
of your destructors panics? The process aborts, is what happens. You've setup
all this machinery for apparently nothing at all. And generating all the
machinery for unwinding is a hit to compile time, bloats binary sizes, and can
potentially thwart optimizations in the generated code.

I don't think it would be uncontroversial to provide unwinding as an option.
The biggest question here is whether or not that option would be enabled or
disabled by default, as it would have implications for distributing compiled
binaries (though perhaps Cargo could assist with this).

