Qual è l'approccio corretto alla gestione delle eccezioni in iOS?

Question

Ho appreso che l'Objective C ha un modo equivalente di gestire eccezioni come C# in .NET. Inoltre, come dice la documentazione Apple, mi piacerebbe gestire/elaborare le eccezioni, creando un oggetto NSError. Dando uno sguardo da vicino la sezione "Catching diversi tipi di eccezione" nella documentazione exception handling

.... Vorrei catturare diversi tipi di eccezione. In. NET Sono abituato a consultare il doc di un metodo di classe per ottenere le possibili eccezioni che può generare. Dove ottenere queste informazioni dai apple-docs? Come faccio a sapere, che tipo di eccezioni un metodo/oggetto/processo può sollevare?

grazie per i vostri suggerimenti

Tom

Answer 1

Come afferma la documentazione di Apple, la maggior parte delle eccezioni viene lanciata in circostanze eccezionali. (Alcune eccezioni non lo sono, come l'accesso a un oggetto dai limiti NSArray.)

.NET incoraggia la gestione delle eccezioni locali. Il cacao è stato scritto per incoraggiare la gestione delle eccezioni di ampio raggio. Il motivo per cui la gestione delle eccezioni locali è in .NET è che ci si aspetta che una parte fallisca in modo atteso (come un errore di rete durante il download di qualcosa). In Cocoa, questo viene gestito utilizzando metodi che restituiscono invece NSErrors. È la stessa cosa, solo più visibile nella firma del metodo.

Una buona regola empirica è che Cocoa emette solo un'eccezione in situazioni in cui non è chiaro come si possa recuperare. (Non confondere questo per le eccezioni che sono gettati in tutto il luogo come in .NET e essendo questo difficile da gestire.)

Answer 2

sguardo al developer reference for exception handling. Nel cacao non riceviamo eccezioni come nilArgumentException, otteniamo solo NSException. Per dare bel messaggio grana o la manipolazione è possibile effettuare le seguenti operazioni,

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

Di seguito l'elenco dei nomi di eccezione definiti nel file di intestazione 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; 

CORREZIONE:

È possibile creare una sottoclasse di classe NSException, come suggerito in uno dei commenti qui sotto, per la cattura di eccezione personalizzata.

Answer 3

movimentazione nel mondo Objective-C errore è probabilmente molto diverso da quello a cui siete abituati . Per dirla in breve, dimentica le eccezioni. La maggior parte degli errori sono gestite da valori di ritorno o passando un puntatore a NSError*:

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

E sul lato callee:

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

Questo sembra ingombrante, ma in pratica funziona per lo più bene. Nella rara occasione in cui qualcosa può davvero lanciare un'eccezione (come [NSFileHandle writeData:]), la documentazione menziona il fatto, ma non penso che ci si aspetti che analizzi l'eccezione tanto quanto di consueto in altre lingue.