Swift Asserts

https://www.mikeash.com/pyblog/friday-qa-2016-03-04-swift-asserts.html

by ingve • 10 years ago

73 21 10 years ago

mattiemass• 10 years ago

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.

mikeash6• 10 years ago

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• 10 years ago

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

jcizzle3• 10 years ago

Yes, but that is just the default behavior, does this not work?

    NSSetUncaughtExceptionHandler({exception in
       print("\(exception)")
       exit(1)
    });

bsaul2• 10 years ago

But then, throwing exceptions instead of just crashing the app can also let tools like crashlytics get them and send them to a web service before the app really terminates.

_greim_• 10 years ago

Observation: JavaScript runtime errors don't crash my browser tab, just halt the current call stack. I wonder if that's a consequence of bad/adhoc architecture, or if browsers represent a class of apps where silently swallowing errors is the right thing to do?

astrange2• 10 years ago

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!

There's a defaults setting you can use that will pop up a window with crash/continue options if it catches your NSException.

But it is inconsistent - some old stuff like NSInvocation also catches and throws out exceptions, but dispatch queues will kill your process if they catch one.

kibwen• 10 years ago

This is also something that Rust encourages. The default `assert!()` macro remains in even in release builds, and you may use the `debug_assert!()` macro to have the assertion present only in debug builds.

kinofcain• 10 years ago

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

Swift Asserts

Related Stories