Swift Assertions behaviour in production applicati

问题:

I'm reading the Assertions section in the Swift e-book and it looks like assertions work very similarly to their Objective-C counterparts. However, nowhere in the docs can I find anything about runtime behaviour while running as a production app. Objective-C's NSAssert promises never to terminate a production application as a result of an assertion failure. Is it the same case in Swift?

回答1:

Based upon the language Apple use in their documentation, I'd say assertions are ignored in a production environment.

If your code triggers an assertion while running in a debug environment, such as when you build and run an app in Xcode, you can see exactly where the invalid state occurred and query the state of your app at the time that the assertion was triggered. An assertion also lets you provide a suitable debug message as to the nature of the assert.

And in the "Note" block:

Assertions cause your app to terminate and are not a substitute for designing your code in such a way that invalid conditions are unlikely to arise. Nonetheless, in situations where invalid conditions are possible, an assertion is an effective way to ensure that such conditions are highlighted and noticed during development, before your app is published.

回答2:

The difference between debug and release is the difference between compiler arguments. The most likely answer is that there will be some special compiler settings (similar to -ea in Java).

EDIT
The Swift compiler has an argument called -assert-config

-assert-config Specify the assert_configuration replacement. Possible values are Debug, Release, Replacement.

In Release, the assertions are ignored. Not sure about the difference between Debug and Replacement.

回答3:

Asserts are documented along with preconditions in the Swift standard library documentation.

• Debug -> Stop on assertion failure.
• Release -> Compile with assertions ignored
• Release and "Disable safety checks" -> Assume all assertion statements are statements of truth and hints to the compiler so that following and preceding code may be removed if only reached in conditions where the assertion would have failed. This means that if you follow the assertion by code on handle the exceptional case it may be ignored. If the assertion would ever have failed the behaviour is completely undefined.

I've not checked but the "Disable safety checks" may correlate with the -assert-config Replacement that @Sulthan mentions.

回答4:

Check your Optimization Level and make sure it is not Onone for release configuration. See my note https://github.com/onmyway133/blog/issues/39