title: Using Exception Handling versus NSError in Cocoa Apps
body: <p>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?)</p>
  
  <p>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. </p>
  
  <p>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.</p>
  
  <p>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:</p>
  
  <pre><code>- (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 ,&amp;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;
  
  }
  </code></pre>
  
  <p>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. </p>
  
  <p>Like so..</p>
  
  <pre><code>    ...
  
      @try
      {
        OSStatus err = OpenFileReference((CFURLRef)filePath ,&amp;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;
  </code></pre>
  
  <p>Am I crazy in thinking that this is a much more elegant solution with less redundant code?
  Did I miss something?</p>