|
|
|
|
|
|
by jcelerier
1504 days ago
|
|
|
> 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) |
|
|
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.