[Snarwin]

The problem with this approach is that, when a panic actually happens at runtime, there is no way to tell whether it was caused by an isolated mistake like forgetting to check for zero, or by memory corruption writing garbage all over your data structures. If it's the first, recovering is fine; if it's the second, you risk exposing the user to data loss and security vulnerabilities. So the only safe thing to do is crash.

Now, it may be true that you get better reviews selling software that corrupts data or gets its users hacked than selling software that crashes. But unless you hate your users, those are probably things you want to avoid.

[Tainnor]

In memory-safe languages, memory is not suddenly corrupted because of some exception that is thrown.

Instead, the bigger issue is corrupt external state, e.g. in a database. But that can of course happen just as well if you panic. What you'll need to do is to wrap your code in a transaction, if possible.

[int_19h]

Corrupt internal state is just as much of a problem. It doesn't have to be corruption in a sense of garbage memory. It just has to violate invariants - say, one variable got updated, and the other one that depends on it did not.

[Tainnor]

But that doesn't just happen on its own just because an exception is thrown.

Either you don't handle it and it kills the process, or you handle it at the top level of a web server or similar, and it just kills that request (and that doesn't affect other requests), or you've written explicit error handling logic in which case you've hopefully thought about how to handle the error so as not to carry garbage, inconsistent state around, and hopefully also written some tests for it. This gets even easier if you mostly use immutable data, or at least limit shared state between components.

GGP's original point was that "the only safe thing to do [when encountering an exception] is crash" and for managed-memory-languages that is simply not true.

[int_19h]

It happens because a piece of code that was supposed to execute atomically ended up having an exception in the middle - so one assignment did execute, while the other one did not.

If you can well and truly isolate the state that concerns a single request from any other state, then yes, it is safe. The problem is proving that such isolation holds.

Memory-safe or not doesn't actually matter much here.