[jcelerier]

I don't understand your #2 (or your whole point). It's exactly the case for exceptions and how exceptions happen. "You won't get an exception if your code is written correctly and the inputs of your program match your programmer expectations" yeah maybe two year down the line someone refactors the code which was resizing the vector before and now you have the most run-of-the-mill exception ; I just hope that someone making an app with your library has a way to catch the panic so that the software doesn't crash but shows a helpful error dialog to your user and makes a backup of its data before softly existing instead, otherwise we're really back at the pre-1980 state of the art of software design

[Hackbraten]

> maybe two year down the line someone refactors the code which was resizing the vector before and now you have the most run-of-the-mill exception

In other words: there’s a bug in the code, and that bug has now caused an unrecoverable error, panicking the thread. Now the thread has died (or maybe caught the panic to present a friendly error message). Either way, the user is now aware of the bug, and disaster has been avoided.

Of all situations where your app might want to create a backup of its state, why would you choose to do so precisely while unwinding a crashed thread, where all assumptions, bets and invariants are already off?

And what would the helpful error dialog even say? „A problem has occurred and the app will now shut down“? From the user’s point of view, is that really an actionable or helpful error dialog?

[jcelerier]

> And what would the helpful error dialog even say? „A problem has occurred and the app will now shut down“? From the user’s point of view, is that really an actionable or helpful error dialog?

Yes, literally. This is already much better than anything that gets the spinning ball of death of macOS going. You can even continue if you are running an event-driven app where the error may have happened as part of an event handler (and thus limited to a very specific part of the software).

To give my own experience: I develop https://ossia.io and use this catch-all method. In 7 years I've gotten numerous thanks from the users for it not crashing but being able to carry forward in case some issue crops up in a sub-sub-sub-module. Not a single time I remember this to cause some memory corruption later.

(backing up state is done up to the previous user action but while in my case it works, it's not always practical)

[tialaramex]

So in this space, you might well feel confident that catch_unwind() is appropriate, although I still think the thread solution is more elegant.

I suspect in reality most of the problems this would catch in OSSIA wouldn't end up as panics in a hypothetical "Rust OSSIA" because of the different attitudes to exception throwing/ panic vs "normal" error flow in these languages and libraries - unless you got really happy slapping "unwrap()" on things when you shouldn't, but sure, it would solve this problem.

As to memory corruption - the problem isn't strictly "memory corruption" but unstable system state. If my underlying cause is that somebody's dubious Leslie simulator blows up when I frob the gain control on it too quickly, restoring exactly the state in which it blew up last time doesn't help me on its own. I need some way to say OK, that was crazy, no Leslie simulator until I save the project and then we can take it gently, which again is somewhere the thread solution is nicer.