Debugging with assert()
Debugging with assert() 관련
One level up from print() are assertions, which are debug-only checks that will force your app to crash if a specific condition isn't true.
On the surface, that sounds terrible: why would you want your app to crash? There are two reasons. First, sometimes making your app crash is the Least Bad Option: if something has gone catastrophically wrong – if some fundamentally important file is not where it should be – then it may be the case that continuing your app will cause irreparable harm to user data, in which case crashing, while a bad result, is better than losing data.
Second, these assertion crashes only happen while you’re debugging. When you build a release version of your app – i.e., when you ship your app to the App Store – Xcode automatically disables your assertions so they won’t reach your users. This means you can set up an extremely strict environment while you’re developing, ensuring that all values are present and correct, without causing problems for real users.
Here's a very basic example:
assert(1 == 1, "Maths failure!")
assert(1 == 2, "Maths failure!")
As you can see assert() takes two parameters: something to check, and a message to print out of the check fails. If the check evaluates to false, your app will be forced to crash because you know it's not in a safe state, and you'll see the error message in the debug console. You can – and should! – add these assertions liberally to your code, because they help guarantee that your code’s state is what you think it is.
The advantage to assertions is that their check code is never executed in a live app, so your users are never aware of their presence. This is different from print(), which would remain in your code if you shipped it, albeit mostly invisible. In fact, because calls to assert() are ignored in release builds of your app, you can do complex checks:
assert(myReallySlowMethod() == true, "The slow method returned false, which is a bad thing!")
That myReallySlowMethod() call will execute only while you’re running test builds – that code will be removed entirely when you build for the App Store.
So: assertions are like running your code in strict mode. If your app works great with assertions on – things that literally make your app crash if things are wrong – then it will work even better in release mode.