Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> Silent failure is ultimately terrible for users.

Agreed.

Unfortunately, crashes in iOS are “silent failures,” and are a loss of control.

What this practice does, is give me the option to handle the failure “noisily,” and in a controlled manner; even if just emitting a log entry, before calling a system failure. That can be quite helpful, in threading. Also, it gives me the option to have a valid value applied, if there’s a structural failure.

But the main reason that I do that with @IBOutlets, is that it forces me to acknowledge, throughout the rest of the code, that it’s an optional. I could always treat implicit optionals as if they were explicit, anyway. This just forces me to.

I have a bunch of practices that folks can laugh at, but my stuff works pretty effectively, and I sleep well.





Crashes are silent failures but as I mentioned: you can get a lot of your crashes reported via the App Store. This is why I prefer crashes in this situation: it gives me something actionable over silent failures on the client.

But nothing beats catching the problem before the crash.

Also, I have found App Store crash reports to be next to useless. TestFlight ones are a bit better.

But if I spend a lot of time, doing it right, the first time, we can avoid all kinds of heartbreak.


And you will find the problem very early if you crash. You are much less likely to find the problem if you don’t.

What have you found useless about the crash reports from the App Store? It would be really nice for it to have something like a breadcrumb capability, but typically the stack trace of the crash is sufficient to see what went wrong.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: