[ctdonath]

That’s fine IF they can prove it won’t crash or that a crash is appropriate (a la forced exit). Too many developers use it as a happy path shortcut, not considering the compiler is warning of possible serious problems.

Crashes & exits are not acceptable in production code, and I’ve had to fix too many of them.

[saagarjha]

I strongly disagree. I would rather an application crashed and provided me with an actionable crash report rather than it continuing on in some random state. (This isn't to say that you should ignore errors; it's just that if you don't think there should be an error at a certain location, I would really want to know about it if there is one.)

[ctdonath]

That's why force-unwrap is so bad: the compiler is telling you there's a risk, at a time you can do something sensible about it, and force-unwrap puts solving the problem off to the worst possible scenario. My production user base can't afford "actionable crash reporting" as a debugging tool vs compiler warnings; even 0.01% of users experiencing it would get very expensive.

[alkonaut]

If a thing can’t be null/nothing and there is nothing you can do it’s usually best to tear the world down. Otherwise in the best case you have a button that does nothing but in the worst case something bad happens. In the normal case the crash just moves. “Catching” programmer errors because a program that limps along looks better than one that crashes is a design decision I never understood.

[swatcoder]

If "a thing can't be null/nothing", then you've made an error in making it an optional.

If a thing might be null/nothing but can't be used when it is, then you should write code that indicates your understanding of that case. Catching an error doesn't imply that your program should proceed, it communicates that you the programmer understood your system and anticipated its failure states. Proceeding or aborting is a secondary decision.

[ken]

> If "a thing can't be null/nothing", then you've made an error in making it an optional.

I don't disagree with this, but I can point out gobs of places in AppKit where Apple has arguably 'made an error' and I can't do anything about it. Or in third-party C libraries, which hold 99% of the functionality I ultimately need, and were not designed for having nice Swift programming interfaces.

I feel like everyone saying "never force unwrap!" must be writing pure-Swift standalone functions, with no dependencies, including the operating system. The API for writing items to the Mac clipboard still documents that it can throw exceptions, which are impossible to catch in Swift!

[alkonaut]

Exactly. And in many languages that is quite difficult to ensure at compile time. In java all object parameters are by definition optoinal. Same thing in C# (before C#8 brought non-nullable types).

Obviously in F# or Haskell or C#8 or Rust this isn't a problem. But what we are talking about is: how do you handle, at runtime, in a language such as C#7 or Java, an null parameter being passed to a method that must return a value based on its parameter, but was passed null? It's a choice between very bad options where the least bad is usually to throw an ArgumentNullException or similar. Because there is nothing better to do.

[saagarjha]

> If "a thing can't be null/nothing", then you've made an error in making it an optional.

There are cases where the programmer cannot express this to the compiler without a bottom type.

[panic]

It's not just that it looks better. It can give the person using the software a chance to save their data.

[alkonaut]

That one should always do of course (but perhaps not to the default place because there is every chance the data is already corrupted)

[saagarjha]

Yes, and I'm usually happy the compiler is there to warn me. However, the compiler is not great at telling me why something might fail, which can make it difficult to provide decent error handling. And of course, there are certain places where the compiler just cannot know that a certain operation will not fail.

[ctdonath]

That's why you use it only when you can prove it won't fail. I'm ok with that, and said so at the start.

[rimliu]

I've inherited an Swift app once that was written by the dev for whom it was the first Swift project. IUOs everywhere. And the biggest contributor to the crash count. Spend six months cleaning it up; the crash rate went down dramatically. It is not wise some value will always be there when you do not control its source (e.g. API).

[saagarjha]

> I've inherited an Swift app once that was written by the dev for whom it was the first Swift project. IUOs everywhere.

Right, hence why I'm suggesting that they can be useful if you don't put them everywhere and aren't using them as a band-aid to make your code compile :)