Oigan todos. He estado leyendo sobre las sugerencias de Apple sobre cuándo / dónde / cómo usar NSError versus @ try / @ catch / @ finalmente. Esencialmente, mi impresión es que Apple piensa que es mejor evitar el uso de construcciones de lenguaje de manejo de excepciones, excepto como un mecanismo para detener la ejecución del programa en situaciones de error inesperadas (¿tal vez alguien podría dar un ejemplo de tal situación?)

Vengo de Java, donde las excepciones son el camino a seguir cuando uno quiere manejar los errores. Es cierto que todavía estoy en el espacio mental de Java, pero poco a poco me estoy dando cuenta de todo lo que NSError tiene para ofrecer.

Una cosa de la que estoy colgado es la tarea de limpiar la memoria cuando se produce un error. En muchas situaciones (por ejemplo, utilizando las bibliotecas C, C ++, CoreFoundation, etc.), se debe realizar una gran cantidad de limpieza de memoria antes de salir de una función debido a un error.

Aquí hay un ejemplo que inventé que refleja con precisión las situaciones que he estado encontrando. Usando algunas estructuras de datos imaginarios, la función abre un identificador de archivo y crea un objeto 'MyFileRefInfo' que contiene información sobre qué hacer con el archivo. Algunas cosas se hacen con el archivo antes de que el identificador de archivo se cierre y la memoria para la estructura se libere. Usando las sugerencias de Apple tengo este método:

- (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;

}

Ahora ... mi lógica Java me dice que sería mejor configurar esto como una estructura try / catch / finally y poner todas las llamadas para cerrar el identificador del archivo y liberar memoria en el bloque finally.

Al igual que..

    ...

    @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;

¿Estoy loco pensando que esta es una solución mucho más elegante con menos código redundante? ¿Me he perdido algo?