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.
Swift helps a lot. It has a lot of safety in it. I haven’t had a memory leak in ages.
Also, Xcode has gotten really good at letting me know when I have a future crash.