I'm not really a fan of auto-restart on crash. In some cases, it could cause damage.
I consider a crash -any crash, to be my fault. This includes things like yanking out the power cord (which probably will just stop the program counter, as opposed to careening off into the weeds).
No matter how abusive the user is, no matter how out-of-band their behavior, my software should never crash.
I love crashes. They tend to be easy to fix (of course, thread collisions are another matter). If I can reliably reproduce a crash, I can usually fix it in a few minutes.
In iOS, Apple makes it impossible to quit an app. I have heard of developers deliberately forcing a crash to do that, but, if Apple catches you doing it, they'll yank the app. They won't approve apps they can get to crash. In fact, they have, in the past, found crashes that I missed.
Just better off, writing software that can handle always-on, and that doesn't crash.
Back in the mists of time when writing cross platform software for any platform (Mac, Win < 95, SunOS + xview) each platform had bugs and we’d have to take pains to workaround them. Our customers didn’t care whose fault it was.
It used to be that a single tech support call cost us any profit from 3 copies of the product.
Things are different now though - the frameworks on platforms have orders of magnitude more surface and complexity. And most small companies don’t offer 1-1 support anymore.
Failing to account for platform behaviors can be your fault, but it doesn’t mean you can account for them at all times. If you put something in user defaults and cfprefsd crashes at that moment, you might lose a value you stored: should your code handle that? Probably not. In this case you could say “well I could try again, or check to make sure I really saved the data” but can you really? Are you going to write an exponential backoff algorithm to raise your confidence of consistency for each setting you write? Much less for all the other things that can break? Sometimes the appropriate thing to do is get the crash log that the GPU failed and if they ask you about it you read and tell them what happened.
I’ll be a bit pedantic and say, that even by the Swift (or rust) language:
1. Crashes aren’t unsafe. They’re actually preferable for both Swift and rust than getting into an unsafe state with incorrect data. So in that sense, crashes are the seen as safe, just undesirable as an outcome.
2. Memory leaks can’t be unsafe any more than a badly optimized algorithm.
But yes, they’re sloppy and should be avoided. I just contend that there’s no real case where I think they should be considered unsafe from the model of a programming language.
They might be unsafe from the model of a context specific use. E.g you wouldn’t want a memory leak locking up your system in vehicular automation. But I’d fall back to it just being sloppy programming if that state is achieved.
That comes back around to whether the user or the platform is the reason for the crash. If a user puts in something weird then it’s your job to fix that, almost always.
I consider a crash -any crash, to be my fault. This includes things like yanking out the power cord (which probably will just stop the program counter, as opposed to careening off into the weeds).
No matter how abusive the user is, no matter how out-of-band their behavior, my software should never crash.
I love crashes. They tend to be easy to fix (of course, thread collisions are another matter). If I can reliably reproduce a crash, I can usually fix it in a few minutes.
In iOS, Apple makes it impossible to quit an app. I have heard of developers deliberately forcing a crash to do that, but, if Apple catches you doing it, they'll yank the app. They won't approve apps they can get to crash. In fact, they have, in the past, found crashes that I missed.
Just better off, writing software that can handle always-on, and that doesn't crash.