Learn Objective-C on the Mac - Mark Dalrymple [127]
Realizing You Have an Error
So now you know a little bit about the NSError class. But, where do they come from? Unlike exceptions, NSError objects don’t do anything to change the flow of your code. Typically, an NSError instance is returned to you from a method call, not as the return value but by referencing a pointer you pass in. This form of parameter twiddling is not too uncommon in C, but still fairly uncommon in Objective-C. The idea is that an error-prone method should receive as a parameter a pointer to an NSError pointer. Which means you don’t pass in a pointer itself, but the address of a pointer variable so that the receiving method can create an object and assign your pointer to it!
This may sound confusing, but once you see the pattern, things should clear up. As an example, consider the NSFileManager class. The file manager lets you do perform certain disk operations such as creating directories, accessing file attributes, and so on. It has a method whose signature looks like this:
We can use this method to access a dictionary containing a whole lot of relevant file system information about the file or directory specified in the path parameter. Note that the second parameter, error, is of type NSError**, which means that we pass in a pointer to a variable that can point at an NSError. If the method actually encounters an error situation, it will create an NSError, and stick its address in the location specified by error. If you want to ignore any error that a method like this produces, you can pass in the special NULL pointer as the last parameter.
The following method shows what this looks like from the caller’s perspective. We create a variable which can point at an NSError, and initialize it to point at nil. Then we pass the address of that variable to a potentially error-generating method, and afterwards check the variable to see whether or not it’s still pointing at nil. If not, we know that the method encountered an error, and we ask the application to present the error to the user.
For simplicity’s sake, while exploring NSError we’ll continue building onto the project we’re already playing with. Add the fileError method shown previously to your app delegate class, and add a [self fileError]; line to the applicationDidFinishLaunching: method. Build & Run, and you’ll see something like the alert panel shown in Figure 12-4.
Figure 12-4. No error here!
Now go back and edit the fileManager call, changing the string parameter from @“/tmp” to @“/tmpfoo” or some other non-existent path. This will cause fileManager to encounter an error and give it back to us, in the fileError variable whose address we passed in. We notice this error and pass it off to NSApp, resulting in the alert panel shown in Figure 12-5.
Figure 12-5. There’s the error.
That’s all fine and good, but look at the text in that alert panel: The file “tmpfoo” does not exist. Doesn’t that seem a little... non-technical? Aren’t we used to a bit more jargony language in our computer systems? After all, the error was triggered by a low-level system routine which reported just an error number and nothing else. Where did that text come from?
It turns out that NSError has a method called localizedDescription, which gives you a nice, human-readable explanation of the error. This description is what’s eventually displayed by the reportError: method.
Let’s explore this a bit by using the debugger. In Xcode, set a breakpoint on the line containing [NSApp presentError:fileError] by clicking in the “gutter” to the left of the line in the text editor. The gutter is the space where the line numbers are shown. This is the most straightforward way to set a breakpoint in your own code. Then restart your app, this time in the debugger. The app will halt at the chosen line, leaving you with the gdb prompt in the output console.