Using Exception Handling versus NSError in Cocoa Apps - objective-c

Question

Hey all. I've been reading up on Apple's suggestions for when/where/how to use NSError versus #try/#catch/#finally. Essentially, my impression is that Apple thinks it best to avoid the use of exception handling language constructs except as a mechanism for halting program execution in unexpected error situations (maybe someone could give an example of such a situation?)
I come from Java, where exceptions are the way to go when one wants to handle errors. Admittedly, I'm still in the Java thoughtspace, but I'm slowly coming to grips with all that NSError has to offer.
One thing I'm hung up on is the task of cleaning up memory when an error occurs. In many situations (e.g. using C, C++ libraries, CoreFoundation, etc..) you have a lot of memory cleanup that needs to be done before breaking out of a function due to an error.
Here's an example I cooked up that accurately reflects the situations I've been encountering. Using some imaginary data structures, the function opens up a file handle and creates a 'MyFileRefInfo' object which contains information about what to do with the file. Some stuff is done with the file before the file handle is closed and the memory for the struct freed. Using Apple's suggestions I have this method:
- (BOOL)doSomeThingsWithFile:(NSURL *)filePath error:(NSError **)error
{
MyFileReference inFile; // Lets say this is a CF struct that opens a file reference
MyFileRefInfo *fileInfo = new MyFileRefInfo(...some init parameters...);
OSStatus err = OpenFileReference((CFURLRef)filePath ,&inFile);
if(err != NoErr)
{
*error = [NSError errorWithDomain:#"myDomain" code:99 userInfo:nil];
delete fileInfo;
return NO;
}
err = DoSomeStuffWithTheFileAndInfo(inFile,fileInfo);
if(err != NoErr)
{
*error = [NSError errorWithDomain:#"myDomain" code:100 userInfo:nil];
CloseFileHandle(inFile); // if we don't do this bad things happen
delete fileInfo;
return NO;
}
err = DoSomeOtherStuffWithTheFile(inFile,fileInfo);
if(err != NoErr)
{
*error = [NSError errorWithDomain:#"myDomain" code:101 userInfo:nil];
CloseFileHandle(inFile); // if we don't do this bad things happen
delete fileInfo;
return NO;
}
CloseFileHandle(inFile);
delete fileInfo;
return YES;
}
Now.. my Java logic tells me that it would be better to set this up as a try/catch/finally structure and put all the calls to close the file handle and free memory in the finally block.
Like so..
...
#try
{
OSStatus err = OpenFileReference((CFURLRef)filePath ,&inFile);
if(err != NoErr)
{
... throw some exception complete with error code and description ...
}
err = DoSomeStuffWithTheFileAndInfo(inFile,fileInfo);
if(err != NoErr)
{
... throw some exception ...
}
... etc ...
}
#catch(MyException *ex)
{
*error = [NSError errorWithDomain:#"myDomain" code:[ex errorCode] userInfo:nil];
return NO;
}
#finally
{
CloseFileHandle(inFile); // if we don't do this bad things happen
delete fileInfo;
}
return YES;
Am I crazy in thinking that this is a much more elegant solution with less redundant code?
Did I miss something?

Answer 1

Daniel's answer is correct, but this question deserves a rather more blunt answer.
Throw an exception only when a non-recoverable error is encountered.
Use NSError when communicating error conditions that may be recovered from.
Any exception that is thrown through a frame in Apple's frameworks may result in undefined behavior.
There is an Exceptions programming topic document available in the dev center.

Answer 2

Essentially, my impression is that Apple thinks it best to avoid the use of exception handling language constructs except as a mechanism for halting program execution in unexpected error situations (maybe someone could give an example of such a situation?)
That's not quite my impression. I thought that Apple suggests using exceptions for truly exceptional conditions, and NSError for expected failures. Since you come from Java, I think NSError -> java.lang.Exception, and Obj-C Exceptions -> java.lang.RuntimeException. Use an Obj-C exception when the programmer did something wrong (used an API incorrectly, for example), and use NSError when an expected failure occurred (the remote server could not be found, for example).
Of course, that's just my interpretation of Apple's position. I, on the other hand, like exceptions!

Answer 3

Exceptions in Objective-C have historically been 'heavy', with a performance cost to entering a try block, a cost to throwing, a cost to using finally, etc. As a result Cocoa developers have typically avoided exceptions outside of 'oh no, the sky is falling' sorts of situations -- if a file is missing, use an NSError, but if there's no filesystem and a negative amount of free memory, that's an exception.
That's the historical view. But if you're building a 64-bit app on 10.5 or newer, the exception architecture has been rewritten to be 'zero cost', which may mean that the historical view is no longer relevant. As with just about anything, it comes down to various factors -- if working one way is more natural to you and will let you finish more quickly, and if you don't experience any performance-related problems with it, and if being slightly inconsistent with 'traditional' Objective-C code doesn't bother you... then there's no reason not to use exceptions.

Answer 4

According to More iPhone 3 Development by Dave Mark and Jeff LeMarche, exceptions in are used only for truly exceptional situations and usually indicate a problem within your code. You should never use exceptions to report a run-of-the-mill error condition. Exceptions are used with much less frequency in Objective-C than in many other languages, such as Java and C++.
You use an exception when you need to catch a mistake in your code. You use an error when the user may need to fix the problem.
Here's an example where you would use an exception:
We're writing a superclass, and we want to make sure its subclasses implement a given method. Objective-C doesn't have abstract classes, and it lacks a mechanism to force a subclass to implement a given method. Yet we can use an exception to instantly inform us that we forgot to implement the method in a subclass. Instead of an unpredictable behavior, we'll get slammed with a runtime exception. We can easily debug it because our exception will tell us exactly what we did wrong:
NSException *ex = [NSException exceptionWithName:#"Abstract Method Not Overridden" reason:NSLocalizedString(#"You MUST override the save method", #"You MUST override the save method") userInfo:nil];
[ex raise];
Because problem is a programmer mistake rather than a problem the user may be able to fix, we use an exception.