È buona norma estendere NSError

Question

Ci scusiamo per questa domanda. So che in Java stiamo estendendo la classe Exception per le eccezioni personalizzate. Ma non vedo nessuno scenario per quello nell'obiettivo c.

Quindi la mia domanda, è una buona pratica estendere NSError e introdurre errori personalizzati? In tal caso, quando dovremmo estendere la classe NSError. Ho controllato anche la documentazione. Ma non riesco a vedere le note di override per NSError.

Answer 1

Non l'ho mai visto e perché NSError è già molto versatile. Consente di definire il tipo di errore impostando le proprietà domain e code e consente di allegare informazioni aggiuntive arbitrarie all'interno del dizionario userInfo.

Quindi, no, non è una buona pratica.

Answer 2

Mentre sono d'accordo sul fatto che non si dovrebbe sottoclasse NSError, è molto utile mettere le categorie su di esso, e lo faccio regolarmente. Ad esempio, supponiamo che il tuo sistema pubblichi spesso errori provenienti da alcuni blocchi JSON. Avrei trovato molto conveniente per creare una categoria come:

@interface NSError (MyErrors) 
// Construct an NSError from data in JSON. 
// Include full JSON response in the userInfo 
+ (NSError *)myErrorWithJSON:(JSON *)json; 

// Parse the text out of the user info 
- (NSString *)myErrorMessage; 

// The full JSON error block as a string 
- (NSString *)myErrorJSON; 

// BOOLs can be helpful sometimes, or you could return an enum for use in a switch. 
- (BOOL)myIsNetworkError; 
- (BOOL)myIsAuthError; 
@end 

io scrivo spesso piccoli aiutanti di costruire più NSError semplicemente, costruire il userinfo come voglio, ei dati tirare di nuovo fuori dalla userinfo senza chiamanti bisogno di conoscere la sua rappresentazione interna. Trovo che questa sia una buona forma di nascondere i dati e incoraggia l'uso di messaggi più descrittivi.

Analogamente, anche per i progetti più piccoli, creo spesso un metodo di categoria +myErrorWithCode:localizedDescription:. Conosco il mio dominio, quindi di solito non ho bisogno di passarlo, e questo rende molto più facile impostare la chiave NSLocalizedDescription nelle informazioni utente. Ancora una volta, ciò incoraggia gli errori migliori rendendoli più facili da creare e facilita la modifica dei dettagli di implementazione della gestione degli errori.

Answer 3

Non è una cattiva idea estendere NSError. Ho anche creato una categoria su NSError per mio uso personale. Mi piacerebbe condividerlo con te.

(1) creare un file strings per definire tutti i codici di errore:

/* Following are general error messgaes those we can show to user 
    regarding to Internet connection and request. You can add more 
    codes. */ 

"-1001" = "Connection time out"; 
"-1003" = "Cannot find Host"; 
"-1004" = "Cannot connect to Host"; 
"-1005" = "Server is temporarily down"; 
"-1009" = "The Internet connection appears to be offline"; 
"-1012" = "Authentication failed"; 
"2000" = "This is a custom error message"; // custom created error code 

/* Always describe unknow error with whatever you want in 
    except case (i.e. except error codes). If not mentioned 
    the following line, still you will get message "Unknown error" */ 
"Unknown error" = "Network error occured"; 

(2) fare una categoria sul NSError, diciamo "NSError + ErrorInfo":

@interface NSError (ErrorInfo) 

-(NSString *)userDescription; 

@end 

(3) definirlo:

#define ERROR_KEY(code)     [NSString stringWithFormat:@"%d",code] 
#define ERROR_LOCALIZED_DESCRIPTION(code) NSLocalizedStringFromTable(ERROR_KEY(code),@"Errors",nil) 

@implementation NSError (ErrorInfo) 

-(NSString *)userDescription 
{ 
    NSString *errorDescrption = NSLocalizedStringFromTable(ERROR_KEY(self.code),@"Errors",nil); 

    if (!errorDescrption || [errorDescrption isEqual:ERROR_KEY(self.code)]){ 
     return NSLocalizedStringFromTable(@"Unknown error",@"Errors",nil);; 
    } 

    else{ 
     return ERROR_LOCALIZED_DESCRIPTION(self.code); 
    } 

    return nil; 
} 

@end 

(4) Fare uso di esso:

NSError *yourError; // This can be any NSError object you get 
yourError = [NSError errorWithDomain:@"yourDomain" code:2000 userInfo:details]; // Just for test 
NSLog(@"%@",[yourError userDescription]); 

Answer 4

Nella documentazione è scritto che è ok per sottoclasse:

applicazioni possono scegliere di creare sottoclassi di NSError, ad esempio , per fornire stringhe di errore localizzate migliori sovrascrivendo localizedDescription.

Nel mio caso sto lavorando con OSStatus che è Int32. Il costruttore NSError supporta solo Int. Quindi ho bisogno di sottoclasse per supportare OSSStatus.