
Swift Asserts - ingve
https://www.mikeash.com/pyblog/friday-qa-2016-03-04-swift-asserts.html
======
mattiemass
I'm sooo happy to see prominent developers advocating for leaving sanity
checks (via precondition) on in released builds! Love the article, but love
that recommendation more.

~~~
mikeash
The common wisdom of only having them be active in debug builds baffles me.

Sometimes the argument is from performance. I can buy that.

But the most frequent argument I see is basically, "maybe it'll still work."
Basically, it's rude to crash the app on purpose and lose the user's work when
maybe, _maybe_ , if you keep on going from an assertion failure the program
will still work somehow.

Sure. And maybe you'll crash strangely. And maybe you'll corrupt the user's
data, ruining _all_ of their work, not just whatever you didn't save.

What really drives me nuts is that, on the Mac, _Apple codifies this crazy
idea._ The NSAssert macro throws an exception on failure, and uncaught
exceptions on the main thread get caught by a handler in the event loop which
_logs the exception and continues running the app!_

~~~
DrTung
Reminds me of Objective C happily calling a nil ptr, Apple wants to be
generous and not pester you by terminating your app :-)

~~~
mikeash
That's not really the same. Messaging nil is not necessarily an error. Making
it an error is just an arbitrary language choice. Messaging nil in Objective-C
isn't an uncaught error, but an explicitly allowed action with fully defined
results.

One could certainly argue that making nil messaging an error is better, but
either way it's a different sort of reasoning.

------
kinofcain
Super helpful. I hadn't thought of that use case for @autoclosure but that
makes a ton of sense.

