Learn Objective-C on the Mac - Mark Dalrymple [120]
Our app delegate is going to be a very simple class, containing the applicationDidFinishLaunching: delegate method, which calls three different “utility” methods, each of which demonstrates a common Cocoa pitfall that can result in exceptions being raised at runtime. If all three methods manage to do their work and return, you’ll be rewarded by the appearance of a congratulatory alert panel (just what you always wanted). However, each method has a problem that will raise an exception. Your mission, should you choose to accept it, will be to find and fix each problem. Here’s the complete content of the ExceptionCityAppDelegate.m file:
If you run this code, you’ll see that the promised alert panel won’t appear (but the empty window included in the default nib file will). What will happen, though, is that something like the following will appear in Xcode’s debug output:
If you look back at the invalidArgumentException_unrecognizedSelector method and its comments, you can probably see where this is coming from: our array contains an NSNumber, which doesn’t have a length method, and as a result an exception is raised. We’re not doing anything to explicitly deal with the exception, and it ends up going all the way down the call stack without being handled, which leads to the default behavior mentioned earlier: some info about the exception (specifically, its reason) is logged, and the application skips the rest of the current event. In this case, the event being processed is the application launch, which is already done at this point.
If we hadn’t just pointed out that method for you, things wouldn’t be so clear. The logged exception info doesn’t tell you anything about where it came from, the name of the exception, or anything else that might help you find what part of your code triggered the exception. This is where your new friend, the Xcode debugger, comes in. Every exception that is raised in Cocoa is passed through a C function called objc_exception_throw, so we can set a breakpoint there, and our program will halt in the debugger every time an exception is raised in our application.
THE DEBUGGER
Most developers are probably familiar with the concept of a debugger, which lets you inspect the state of your application while it’s running in order to diagnose problems. If you haven’t encountered a debugger before, here’s a quick rundown of some of the key concepts:■ A breakpoint lets you specify, either with a line number in your source code or the name of a method or function, a spot where the program should halt. When your program has halted, you can examine all CPU registers at that spot in the program’s execution. If you have the source code for the program, you can also access any variables (local, instance, or otherwise) that are relevant at that spot. All CPU registers and available variables are shown in a table view in Xcode’s debug layout.
■ The call stack is the list of all the nested methods and functions that are in operation at any point in time. This appears in a table view in Xcode’s debug layout. When your program is halted, the current method or function appears at the top of the call stack, the method or function that called it appears below it, and so on. You can choose a particular item or “frame” in the call stack in order to switch focus, at which point you’ll see the CPU registers and variables as they were when that method or function called the method or function above it in the call stack.
■ The debugger contains buttons that let you perform some actions relative to the currently highlighted code line. You can step over the current line (which executes