Debugging & Best Practices - Learn SpriteBuilder for iOS Game Development - page 469

When you run the app and it crashes due to an exception, instead of showing the main()
function, Xcode 5 will point to the offending line in your code as shown in Figure 14-5 . If
the exception is raised in an Apple or other framework for which there is no source code
available, Xcode will show the line in your code that makes the call.
Note If the crash wasn't due to an exception, Xcode might still point out the
main() function as the culprit, as shown in Figure 14-2 . In that case, you have
run into a more low-level problem, perhaps a divide-by-zero or buffer-overflow
problem or you're addressing an object that has been released from memory.
Figure 14-5 . With an exception breakpoint added, Xcode 5 shows the line closest to the error for which there
is source code available. Xcode 6 behaves like this by default
Note With an exception breakpoint enabled, the program execution is halted
before the exception message and call stack are printed to the debug console in
Xcode. You can see in Figure 14-5 that the NSAssert message hasn't been
printed to the console. If you need that information, just click the Continue pro-
gram execution button once to see the message and call stack in the console. On
the horizontal toolbar in the center, it's the third icon from the left—the one that
looks like a combined pause and play icon.
Asserting Assumptions
Bugs are unavoidable. They come in many shapes and forms. Code that detects when cur-
rent conditions prevent the code from functioning correctly is essential to avoiding bugs.