Hacker News Reader

Comment by ChrisMarshallNY | Hacker News Reader

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.

View on HN

Crashes are often the result of the platform behaving in unexpected ways, not users.

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.

In my experience, crashes are usually my error.

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.

Memory leaks aren’t unsafe fwiw.

They often result in eventual crashes (but relatively controlled ones), and can affect performance.

So “unsafe” is relative.

In any case, memory leaks are sloppy, and I have a personal aversion to writing sloppy code.

Crashes are not unsafe either.

This is true, everything is sandboxed, these days (but I'm not as sure about MacOS, as I am about iOS).

But it's still a bad look, and Apple won't approve an app, if they can get it to crash -regardless of the reason.

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’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.

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.

Good point.

Reply on news.ycombinator.com