Come posso usare NSError nella mia app per iPhone?


228

Sto lavorando per rilevare errori nella mia app e sto cercando di utilizzarlo NSError. Sono un po 'confuso su come usarlo e su come popolarlo.

Qualcuno potrebbe fornire un esempio su come popolare quindi utilizzare NSError?

Risposte:


473

Bene, quello che faccio di solito è avere i miei metodi che potrebbero fuoriuscire in fase di esecuzione prendere un riferimento a un NSErrorpuntatore. Se qualcosa effettivamente non funziona in quel metodo, posso popolare il NSErrorriferimento con i dati di errore e restituire zero dal metodo.

Esempio:

- (id) endWorldHunger:(id)largeAmountsOfMonies error:(NSError**)error {
    // begin feeding the world's children...
    // it's all going well until....
    if (ohNoImOutOfMonies) {
        // sad, we can't solve world hunger, but we can let people know what went wrong!
        // init dictionary to be used to populate error object
        NSMutableDictionary* details = [NSMutableDictionary dictionary];
        [details setValue:@"ran out of money" forKey:NSLocalizedDescriptionKey];
        // populate the error object with the details
        *error = [NSError errorWithDomain:@"world" code:200 userInfo:details];
        // we couldn't feed the world's children...return nil..sniffle...sniffle
        return nil;
    }
    // wohoo! We fed the world's children. The world is now in lots of debt. But who cares? 
    return YES;
}

Possiamo quindi usare il metodo in questo modo. Non preoccuparti nemmeno di ispezionare l'oggetto errore a meno che il metodo non restituisca zero:

// initialize NSError object
NSError* error = nil;
// try to feed the world
id yayOrNay = [self endWorldHunger:smallAmountsOfMonies error:&error];
if (!yayOrNay) {
   // inspect error
   NSLog(@"%@", [error localizedDescription]);
}
// otherwise the world has been fed. Wow, your code must rock.

Siamo riusciti ad accedere agli errori localizedDescriptionperché abbiamo impostato un valore per NSLocalizedDescriptionKey.

Il posto migliore per ulteriori informazioni è la documentazione di Apple . È davvero buono

C'è anche un tutorial semplice e piacevole su Cocoa Is My Girlfriend .


37
questo è l'esempio più divertente, mai
ming Yeow

questa è una risposta davvero fantastica, anche se ci sono alcuni problemi in ARC e il cast ida BOOL. Qualsiasi leggera variazione compatibile con ARC sarebbe molto apprezzata.
NSTJ,

6
@TomJowett Sarei davvero incazzato se finissimo per non essere in grado di porre fine alla fame nel mondo semplicemente perché Apple ci ha spinto a spostarci nel nuovo mondo unico ARC.
Manav,

1
il tipo restituito può essere BOOL. Restituisci NOin caso di errore e invece di verificare il valore restituito, controlla semplicemente error. Se nilvai avanti, se != nilgestiscilo.
Gabriele Petronella,

8
-1: devi davvero incorporare il codice che verifica che **errornon sia nullo. Altrimenti il ​​programma genererà un errore che è completamente ostile e non rende evidente cosa sta succedendo.
FreeAsInBeer

58

Vorrei aggiungere altri suggerimenti in base alla mia più recente implementazione. Ho esaminato alcuni codici di Apple e penso che il mio codice si comporti in modo molto simile.

I post sopra spiegano già come creare oggetti NSError e restituirli, quindi non mi preoccuperò di quella parte. Proverò solo a suggerire un buon modo per integrare errori (codici, messaggi) nella tua app.


Consiglio di creare 1 header che sarà una panoramica di tutti gli errori del tuo dominio (es. App, libreria, ecc.). La mia intestazione attuale è simile al seguente:

FSError.h

FOUNDATION_EXPORT NSString *const FSMyAppErrorDomain;

enum {
    FSUserNotLoggedInError = 1000,
    FSUserLogoutFailedError,
    FSProfileParsingFailedError,
    FSProfileBadLoginError,
    FSFNIDParsingFailedError,
};

FSError.m

#import "FSError.h" 

NSString *const FSMyAppErrorDomain = @"com.felis.myapp";

Ora, quando si utilizzano i valori sopra riportati per gli errori, Apple creerà alcuni messaggi di errore standard di base per la tua app. È possibile creare un errore come il seguente:

+ (FSProfileInfo *)profileInfoWithData:(NSData *)data error:(NSError **)error
{
    FSProfileInfo *profileInfo = [[FSProfileInfo alloc] init];
    if (profileInfo)
    {
        /* ... lots of parsing code here ... */

        if (profileInfo.username == nil)
        {
            *error = [NSError errorWithDomain:FSMyAppErrorDomain code:FSProfileParsingFailedError userInfo:nil];            
            return nil;
        }
    }
    return profileInfo;
}

Il messaggio di errore standard generato da Apple ( error.localizedDescription) per il codice sopra sarà simile al seguente:

Error Domain=com.felis.myapp Code=1002 "The operation couldn’t be completed. (com.felis.myapp error 1002.)"

Quanto sopra è già abbastanza utile per uno sviluppatore, poiché il messaggio visualizza il dominio in cui si è verificato l'errore e il codice di errore corrispondente. Gli utenti finali non avranno idea di quale codice di errore1002 significhi il , quindi ora abbiamo bisogno di implementare dei bei messaggi per ogni codice.

Per i messaggi di errore dobbiamo tenere presente la localizzazione (anche se non implementiamo subito i messaggi localizzati). Ho usato il seguente approccio nel mio progetto attuale:


1) creare un stringsfile che conterrà gli errori. I file di stringhe sono facilmente localizzabili. Il file potrebbe essere simile al seguente:

FSError.strings

"1000" = "User not logged in.";
"1001" = "Logout failed.";
"1002" = "Parser failed.";
"1003" = "Incorrect username or password.";
"1004" = "Failed to parse FNID."

2) Aggiungi macro per convertire i codici interi in messaggi di errore localizzati. Ho usato 2 macro nel mio file Costanti + Macros.h. Includo sempre questo file nell'intestazione del prefisso ( MyApp-Prefix.pch) per comodità.

Costanti + Macros.h

// error handling ...

#define FS_ERROR_KEY(code)                    [NSString stringWithFormat:@"%d", code]
#define FS_ERROR_LOCALIZED_DESCRIPTION(code)  NSLocalizedStringFromTable(FS_ERROR_KEY(code), @"FSError", nil)

3) Ora è facile mostrare un messaggio di errore intuitivo basato su un codice di errore. Un esempio:

UIAlertView *alert = [[UIAlertView alloc] initWithTitle:@"Error" 
            message:FS_ERROR_LOCALIZED_DESCRIPTION(error.code) 
            delegate:nil 
            cancelButtonTitle:@"OK" 
            otherButtonTitles:nil];
[alert show];

9
Bella risposta! Ma perché non inserire la descrizione localizzata nel dizionario delle informazioni utente a cui appartiene? [Errore NSErrorWithDomain: codice FSMyAppErrorDomain: FSProfileParsingFailedError userInfo: @ {NSLocalizedDescriptionKey: FS_ERROR_LOCALIZED_DESCRIPTION (error.code)}];
Richard Venable,

1
C'è un posto particolare in cui dovrei mettere il file di stringa? Da FS_ERROR_LOCALIZED_DESCRIPTION () sto ricevendo solo il numero (codice di errore).
Huggie,

@Huggie: non so davvero cosa intendi. Di solito inserisco queste macro che uso nell'intera app in un file chiamato Constants+Macros.he lo importa nell'intestazione del prefisso ( .pchfile), quindi è disponibile ovunque. Se intendi che stai utilizzando solo 1 delle 2 macro, potrebbe funzionare. Forse la conversione da inta NSStringnon è davvero necessaria, anche se non l'ho testato.
Wolfgang Schreurs il

@Huggie: ow, penso di capirti ora. Le stringhe dovrebbero essere in un file localizzabile ( .stringsfile), poiché è lì che apparirà la macro di Apple. Leggi sull'uso NSLocalizedStringFromTablequi: developer.apple.com/library/mac/documentation/cocoa/conceptual/…
Wolfgang Schreurs,

1
@Huggie: Sì, ho usato le tabelle di stringhe localizzate. Il codice nella macro FS_ERROR_LOCALIZED_DESCRIPTIONcontrolla la stringa localizzabile in un file chiamato FSError.strings. Potresti voler consultare la guida alla localizzazione di Apple sui .stringsfile se questo ti è estraneo.
Wolfgang Schreurs l'

38

Ottima risposta Alex. Un potenziale problema è la dereferenza NULL. Riferimento di Apple sulla creazione e la restituzione di oggetti NSError

...
[details setValue:@"ran out of money" forKey:NSLocalizedDescriptionKey];

if (error != NULL) {
    // populate the error object with the details
    *error = [NSError errorWithDomain:@"world" code:200 userInfo:details];
}
// we couldn't feed the world's children...return nil..sniffle...sniffle
return nil;
...

30

Objective-C

NSError *err = [NSError errorWithDomain:@"some_domain"
                                   code:100
                               userInfo:@{
                                           NSLocalizedDescriptionKey:@"Something went wrong"
                               }];

Swift 3

let error = NSError(domain: "some_domain",
                      code: 100,
                  userInfo: [NSLocalizedDescriptionKey: "Something went wrong"])

9

Si prega di fare riferimento al seguente tutorial

spero che ti sarà utile, ma prima devi leggere la documentazione di NSError

Questo è un link molto interessante che ho trovato di recente ErrorHandling


3

Proverò a riassumere la grande risposta di Alex e il punto di jlmendezbonini, aggiungendo una modifica che renderà tutto compatibile con ARC (finora non è da quando ARC si lamenterà poiché dovresti tornare id, il che significa "qualsiasi oggetto", ma BOOLnon è un oggetto genere).

- (BOOL) endWorldHunger:(id)largeAmountsOfMonies error:(NSError**)error {
    // begin feeding the world's children...
    // it's all going well until....
    if (ohNoImOutOfMonies) {
        // sad, we can't solve world hunger, but we can let people know what went wrong!
        // init dictionary to be used to populate error object
        NSMutableDictionary* details = [NSMutableDictionary dictionary];
        [details setValue:@"ran out of money" forKey:NSLocalizedDescriptionKey];
        // populate the error object with the details
        if (error != NULL) {
             // populate the error object with the details
             *error = [NSError errorWithDomain:@"world" code:200 userInfo:details];
        }
        // we couldn't feed the world's children...return nil..sniffle...sniffle
        return NO;
    }
    // wohoo! We fed the world's children. The world is now in lots of debt. But who cares? 
    return YES;
}

Ora invece di verificare il valore di ritorno della nostra chiamata al metodo, controlliamo se errorè fermo nil. In caso contrario, abbiamo un problema.

// initialize NSError object
NSError* error = nil;
// try to feed the world
BOOL success = [self endWorldHunger:smallAmountsOfMonies error:&error];
if (!success) {
   // inspect error
   NSLog(@"%@", [error localizedDescription]);
}
// otherwise the world has been fed. Wow, your code must rock.

3
@Gabriela: Apple afferma che quando si utilizzano variabili indirette per restituire errori, il metodo stesso dovrebbe sempre avere un valore di ritorno in caso di successo o fallimento. Apple esorta gli sviluppatori a verificare prima il valore restituito e solo se il valore restituito è in qualche modo non valido, verifica la presenza di errori. Vedere la seguente pagina: developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/…
Wolfgang Schreurs

3

Un altro modello di progettazione che ho visto prevede l'uso di blocchi, che è particolarmente utile quando un metodo viene eseguito in modo asincrono.

Supponiamo che siano definiti i seguenti codici di errore:

typedef NS_ENUM(NSInteger, MyErrorCodes) {
    MyErrorCodesEmptyString = 500,
    MyErrorCodesInvalidURL,
    MyErrorCodesUnableToReachHost,
};

Definiresti il ​​tuo metodo che può generare un errore in questo modo:

- (void)getContentsOfURL:(NSString *)path success:(void(^)(NSString *html))success failure:(void(^)(NSError *error))failure {
    if (path.length == 0) {
        if (failure) {
            failure([NSError errorWithDomain:@"com.example" code:MyErrorCodesEmptyString userInfo:nil]);
        }
        return;
    }

    NSString *htmlContents = @"";

    // Exercise for the reader: get the contents at that URL or raise another error.

    if (success) {
        success(htmlContents);
    }
}

E poi quando lo chiami, non devi preoccuparti di dichiarare l'oggetto NSError (il completamento del codice lo farà per te) o di controllare il valore di ritorno. Puoi semplicemente fornire due blocchi: uno che verrà chiamato quando c'è un'eccezione e uno che viene chiamato quando ha successo:

[self getContentsOfURL:@"http://google.com" success:^(NSString *html) {
    NSLog(@"Contents: %@", html);
} failure:^(NSError *error) {
    NSLog(@"Failed to get contents: %@", error);
    if (error.code == MyErrorCodesEmptyString) { // make sure to check the domain too
        NSLog(@"You must provide a non-empty string");
    }
}];

0

Beh, è ​​un po 'fuori discussione ma nel caso in cui non hai un'opzione per NSError puoi sempre visualizzare l'errore di basso livello:

 NSLog(@"Error = %@ ",[NSString stringWithUTF8String:strerror(errno)]);

0
extension NSError {
    static func defaultError() -> NSError {
        return NSError(domain: "com.app.error.domain", code: 0, userInfo: [NSLocalizedDescriptionKey: "Something went wrong."])
    }
}

che posso usare NSError.defaultError()ogni volta che non ho un oggetto errore valido.

let error = NSError.defaultError()
print(error.localizedDescription) //Something went wrong.
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.