Hacker News Reader

Comment by ChrisMarshallNY | Hacker News Reader

Swift has implicit unwrap (!), and explicit unwrap (?).

I don't like to use implicit unwrap. Even things that are guaranteed to be there, I treat as explicit (For example, (self.view?.isEnabled ?? false), in a view controller, instead of self.view.isEnabled).

I always redefine @IBOutlets from:

    @IBOutlet weak var someView!

to:

    @IBOutlet weak var someView?

I'm kind of a "belt & suspenders" type of guy.

View on HN

So what happens if it ends up being nil? How does your app react?

In this particular case, I would rather crash. It’s easier to spot in a crash report and you get a nice stack trace.

Silent failure is ultimately terrible for users.

Note: for the things I control I try to very explicitly model state in such a way as I never need to force unwrap at all. But for things beyond my control like this situation, I would rather end the program than continue with a state of the world I don’t understand.

Yeah @IBOutlets are generally the one thing that are allowed to be implicitly-unwrapped optionals. They go along with using storyboards & xibs files with Interface Builder. I agree that you really should just crash if you are attempting to access one and it is nil. Either you have done something completely incorrect with regards to initializing and accessing parts of your UI and want to catch that in development, or something has gone horribly, horribly, horribly with UIKit/AppKit and storyboard/xib files are not being loaded properly by the system.

> … you really should just crash if …

See my above/below comment.

A good tool for catching stuff during development, is the humble assert()[0]. We can use precondition()[1], to do the same thing, in ship code.

The main thing is, is to remain in control, as much as possible. Rather than let the PC leave the stack frame, throw the error immediately when it happens.

[0] https://docs.swift.org/swift-book/documentation/the-swift-pr...

[1] https://docs.swift.org/swift-book/documentation/the-swift-pr...

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

This is terrible. The whole reason they introduced this is because IBOutlets would get silently disconnected and then in the field a user would complain that a feature stopped working.

Crash early, crash often. Find the bugs and bad assumptions.

> This is terrible.

No it's not. Read my other comments.

ToMAYto, ToMAHto.

I have learned that it's a bad idea to trash other folks' methodologies without taking the time to understand why they do things, the way they do.

I have found dogma to be an impediment, in my own work. As I've gotten older, the sharp edges have been sanded off.

Have a great day!

> without taking the time to understand why they do things, the way they do.

Oh I am aware. They do it because

A) they don’t have a mental model of correct execution. Events just happen to them with a feeling of powerlessness. So rather than trying to form one they just litter the code with cases things that might happen

> As I've gotten older, the sharp edges have been sanded off.

B) they have grown in bad organizations with bad incentives that penalize the appearance of making mistakes. So they learn to hide them.

For example there might be an initiative that rewards removing crashes in favor of silent error.

Reply on news.ycombinator.com