Learn Objective-C on the Mac - Mark Dalrymple [124]
Make those changes, Build & Run, and you’ll be rewarded with the congratulatory alert panel. Oh, sweet success!
Having tackled those, you’ve now experienced and fixed the main types of runtime exceptions that every Cocoa programmer gets at some point. That’s it! This may come as a surprise to people come from other, more exception-heavy environments, but like we said, in Cocoa exceptions are used sparingly, and almost always to signal that the programmer has made an error. NSRangeException, and NSInvalidArgumentException (for both of the causes shown above) really make up the bulk of all exceptions you’re likely to deal with.
And the Rest
Okay, there are more exceptions that can be raised in a Cocoa app. There are more predefined exception names in NSException.h, for example, but chances are you won’t encounter any of them. NSGenericException seems to arise sometimes when working with SQLite or Apple Events, and on rare occasions NSInternalInconsistencyException can rear its ugly head if you override a method that you shouldn’t (such as when the documentation warns you not to), but real-world examples of those are pretty hard to come by.
The one instance where you’re likely to see any exceptions occur is if you’re using Apple’s Distributed Objects (DO) technology, which uses exceptions in a much more liberal fashion than the rest of Cocoa. For example, DO will raise exceptions to warn you if it loses a connection to the process you’re connected to. Most of the predefined exception names defined by Cocoa, in fact, are specifically for DO’s use. We’re not describing the use of DO in this book, so we won’t say anything more about these exceptions, but it’s good to be aware of in case you go down that path at some point.
Worse than Exceptions: Death by Signal
Now that you’ve seen how some bugs can be handled by code-level operations like catching an exception, it’s time to look at another kind of problem that arises when object pointers are misused. In Cocoa, every Objective-C object is referenced through a pointer to a specific sort of C struct that defines the basic structure of an Objective-C object. If the pointer isn’t pointing either at a chunk of memory containing a valid object, or at nil, then some form of memory access error is almost certain to occur, leading to the creation of a “signal” that ultimately kills your app.
There are two ways that Cocoa programmers inadvertently cause a signal to kill their app. The first way is to try to send a message to an uninitialized object pointer. By default, when you declare a new pointer as a local variable in an Objective-C method, you can’t count on it to automatically point at nil or some other harmless thing. In fact, you can usually rely on it pointing at something completely inappropriate, like a memory address that is not even mapped into the system (the situation is different for instance variables, static local variables, and global variables, which are in fact initialized with nil values). We can examine this by adding the following method to your app delegate:
This method declares a pointer to an NSMutableString, but doesn’t actually create the string. So when it tries to call the appendFormat: method, the receiver isn’t a valid object. To see the effect of this, add a [self uninitializedObject]; line to your applicationDidFinishLaunching: method, build & debug, and watch. Your program will halt, and you’ll see something like this in the Xcode debug console:
Depending on exactly what this uninitialized pointer is pointing at, you may see a different signal name, such as SIGSEGV or SIGILL. As a bonus bit of wrongness, it’s even possible that it could be pointing at some other, valid object in your program, perhaps even an NSMutableString, making it extra-insidious to track down. The specifics don’t