¿Cuál es el enfoque correcto para el manejo de excepciones en iOS?

Question

Me enteré de que Objective C tiene una forma equivalente de manejar excepciones como C# en .NET. Además, como dice Apple Docs, me gustaría manejar/procesar excepciones, creando un objeto NSError. Tomando una mirada cercana a la sección "La captura de diferentes tipos de Excepción" en la documentación exception handling

.... Me gustaría capturar diferentes tipos de excepción. En .NET, estoy acostumbrado a navegar por el documento de un método de clase para obtener las posibles excepciones que puede generar. ¿Dónde obtener esta información de los Apple-Docs? ¿Cómo puedo saber qué tipo de excepciones puede generar un método/objeto/proceso?

gracias por sus sugerencias

Tom

Answer 1

Como dice la documentación de Apple, la mayoría de las excepciones se producen en circunstancias excepcionales. (Algunas excepciones no son, como acceder a un objeto fuera de los límites de NSArray).

.NET fomenta el manejo de excepciones locales. Cocoa está escrito para fomentar el manejo de excepciones de gran alcance. La razón por la que tiene el manejo de excepciones locales en .NET es que espera que alguna parte falle de manera esperada (como un error de red al descargar algo). En Cocoa, esto se maneja usando métodos que devuelven NSErrors. Es lo mismo, solo que más visible en la firma del método.

Una buena regla general es que Cocoa solo arroja una excepción en situaciones donde no está claro cómo se recuperaría. (No confundir esto con excepciones que son lanzadas por todo el lugar como en .NET y siendo esto sea difícil de manejar.)

Answer 2

Mira el developer reference for exception handling. En Cocoa no obtenemos excepciones como nilArgumentException, obtenemos solo NSException. Para dar el mensaje de grano fino o manipulación se puede hacer lo siguiente,

if ([[exception name] isEqualToString:MyAppException]) 

A continuación se muestra la lista de nombres de excepción definidos en el archivo de cabecera NSException.

FOUNDATION_EXPORT NSString * const NSGenericException; 
FOUNDATION_EXPORT NSString * const NSRangeException; 
FOUNDATION_EXPORT NSString * const NSInvalidArgumentException; 
FOUNDATION_EXPORT NSString * const NSInternalInconsistencyException; 

FOUNDATION_EXPORT NSString * const NSMallocException; 

FOUNDATION_EXPORT NSString * const NSObjectInaccessibleException; 
FOUNDATION_EXPORT NSString * const NSObjectNotAvailableException; 
FOUNDATION_EXPORT NSString * const NSDestinationInvalidException; 

FOUNDATION_EXPORT NSString * const NSPortTimeoutException; 
FOUNDATION_EXPORT NSString * const NSInvalidSendPortException; 
FOUNDATION_EXPORT NSString * const NSInvalidReceivePortException; 
FOUNDATION_EXPORT NSString * const NSPortSendException; 
FOUNDATION_EXPORT NSString * const NSPortReceiveException; 

FOUNDATION_EXPORT NSString * const NSOldStyleException; 

CORRECCIÓN:

Usted puede subclase clase NSException, como se sugiere en uno de los comentarios a continuación, para atrapar excepción personalizada.

Answer 3

manipulación en el mundo de Objective-C de error es probablemente muy diferente de lo que estamos acostumbrados . Para decirlo brevemente, olvídate de las excepciones. La mayoría de los errores son manejados por los valores de retorno o pasando un puntero a NSError*:

NSErrror *error = nil; 
BOOL success = [somebody doSomethingWithError:&error]; 
if (!success) { 
    NSLog(@"Got error: %@", error); 
} 

Y en el lado del abonado llamado:

- (BOOL) doSomethingWithError: (NSError**) error 
{ 
    error = error ? error : &(NSError*){ nil }; 
    if (somethingWentWrong) { 
     *error = [NSError …]; 
     return NO; 
    } 
    // All is fine 
    return YES; 
} 

Esto parece complicado, pero en la práctica sobre todo funciona bien. En la rara ocasión en que algo realmente puede arrojar una excepción (como [NSFileHandle writeData:]), la documentación menciona el hecho, pero no creo que deba analizar la excepción tanto como la habitual en otros idiomas.