iPhone-Core-Daten "Produktion" Fehlerbehandlung

Ich gesehen habe in der Beispiel-code geliefert von Apple Hinweise darauf, wie Sie behandeln soll, die Core-Daten-Fehler. I. e:

NSError *error = nil;
if (![context save:&error]) {
/*
 Replace this implementation with code to handle the error appropriately.

 abort() causes the application to generate a crash log and terminate. You should not use this function in a shipping application, although it may be useful during development. If it is not possible to recover from the error, display an alert panel that instructs the user to quit the application by pressing the Home button.
 */
    NSLog(@"Unresolved error %@, %@", error, [error userInfo]);
    abort();
}

Aber nie Beispiele dafür, wie Sie sollte umzusetzen.

Hat jemand (oder kann mir in der Richtung) einige tatsächliche "Produktion" code veranschaulicht die oben genannten Methode.

Vielen Dank im Voraus,
Matt

+1 das ist eine ausgezeichnete Frage.

InformationsquelleAutor Sway | 2010-02-14

32

Niemand wird Ihnen zeigen, production code, da es von 100% auf Ihre Anwendung und wo der Fehler Auftritt.

Persönlich lege ich eine assert-Anweisung in es, weil es zu 99,9% der Zeit, die dieser Fehler auftreten wird in der Entwicklung und wenn Sie die fix it-es ist hoch unwahrscheinlich, dass Sie werden sehen, dass es in der Produktion.

Nachdem die behaupten, ich würde eine Benachrichtigung an den Benutzer, lassen Sie Sie wissen, dass ein nicht behebbarer Fehler aufgetreten ist, und dass die Anwendung verlassen. Sie können auch einen Klappentext, dort bat Sie um Kontaktaufnahme mit dem Entwickler, so dass Sie hoffentlich verfolgen das geschehen.

Nach, ich lasse die abort() gibt, wie es "Abstürzen" der app und generieren Sie einen stack-trace, die Sie hoffentlich später auf die Spur des Problems.
- Marcus - Während Sie behauptet, sind in Ordnung, wenn Sie sprechen, um eine lokale sqlite-Datenbank oder XML-Datei, Sie brauchen eine robuste Fehlerbehandlung Mechanismus, wenn Ihre permanente Speicher ist cloud-basiert.
- Wenn Ihr iOS-Core-Daten persistent zu speichern ist cloud-basiert, haben Sie größere Probleme.
- Hallo @MarcusS.Zarra, hier sagen Sie, dass Sie verwenden Sie abort () - Funktion, aber apple sagt nicht oben verwenden Sie diese Funktion in der Schifffahrt Anwendung. Also, was Sie zu sagen haben
- Ich bin nicht einverstanden mit Apple auf eine Reihe von Themen. Es ist der Unterschied zwischen einer Unterrichts-situation (Apple) und in den Gräben (mich). Aus einer akademischen situation, ja, Sie sollten entfernen Sie bricht. In der Realität, Sie sind nützlich, Sie zu fangen Situationen, die Sie nie für möglich gehalten hätten. Apple-Dokumentation Autoren vorgeben, jede situation ist dafür verantwortlich. Zu 99,999% sind. Was tun Sie für die wirklich unerwartet? Ich Abstürzen, und erzeugen einen log, damit ich herausfinden kann, was passiert ist. Das ist das, was der Abbruch wird für.
- Obwohl, manchmal ist ein speichern: Sie ist nicht erfolgreich, da der ungültige Daten. Wenn Sie verwenden Modell-Validierungen, Ihre app wird Abstürzen aufgrund von etwas, das kann leicht zu erholen. Hinzufügen in einem abort kann bestimmte Spur des Problems, aber in diesem speziellen Fall können Sie auch nicht Abstürzen, und Folgen Sie geeignete Maßnahmen, um die Daten zu korrigieren, so dass das speichern abgeschlossen ist korrekt.
- das ist eine Entwickler-Ebene. Die Eingabe von fehlerhaften Daten ist ein Teil der Prüfung einer Anwendung während der Entwicklung und gefangen werden, bevor die Freigabe für die Produktion. Das ist in der Kategorie "vorhersehbaren problem".
- Ich bin nicht einverstanden: Ein save kann leicht scheitern in der Produktion als auch. Wenn du gerade einen webservice und versuchen, zu speichern abgerufenen Objekte es gibt zahlreiche Dinge, die schief gehen könnte, während der Deserialisierung oder erneute Aufbau von Beziehungen client-Seite. Diese Fehler sind absolut gültig und müssen angemessen gehandhabt werden, verlassen einen sauberen Kontext hinter sich.
- keiner von den Auswirkungen eines core data -save: nennen. Alle diese Bedingungen geschehen, lange bevor der code wäre dieser Punkt erreicht.
- warum ist das so? Wenn ich Deserialisieren eines NSDictionary von einem webservice in ein NSManagedObject und sagen, dass es nicht enthalten ein Feld obligatorisch ist in meinem managedmodel. Wie ist das nicht ein Fehler ausgelöst zu speichern? Das würde nur mit der einfachen rollback zu erwarten, die fehlerhaften webservice-Daten, anstatt die ganze app zu explodieren :/
- Das ist ein erwarteter Fehler, der abgefangen werden kann und korrigiert werden, bevor das sparen. Sie können Fragen, Core Data, wenn die Daten gültig sind, und korrigieren Sie es. Plus können Sie testen, die zum Zeitpunkt der Verbrauch um sicherzustellen, dass alle gültigen Felder vorhanden sind. Das ist ein Entwickler-level-Fehler, die behandelt werden kann, lange bevor die -save: genannt wird.
InformationsquelleAutor Marcus S. Zarra

Dies ist eine generische Methode, die ich kam mit Griff und display-validation-Fehler auf dem iPhone. Aber Marcus hat Recht: würden Sie wahrscheinlich wollen zu optimieren die Nachrichten werden mehr Benutzer freundlich. Aber das vermittelt Ihnen zumindest einen Ausgangspunkt, um zu sehen, was im Feld nicht validiert und warum.

- (void)displayValidationError:(NSError *)anError {
    if (anError && [[anError domain] isEqualToString:@"NSCocoaErrorDomain"]) {
        NSArray *errors = nil;

        //multiple errors?
        if ([anError code] == NSValidationMultipleErrorsError) {
            errors = [[anError userInfo] objectForKey:NSDetailedErrorsKey];
        } else {
            errors = [NSArray arrayWithObject:anError];
        }

        if (errors && [errors count] > 0) {
            NSString *messages = @"Reason(s):\n";

            for (NSError * error in errors) {
                NSString *entityName = [[[[error userInfo] objectForKey:@"NSValidationErrorObject"] entity] name];
                NSString *attributeName = [[error userInfo] objectForKey:@"NSValidationErrorKey"];
                NSString *msg;
                switch ([error code]) {
                    case NSManagedObjectValidationError:
                        msg = @"Generic validation error.";
                        break;
                    case NSValidationMissingMandatoryPropertyError:
                        msg = [NSString stringWithFormat:@"The attribute '%@' mustn't be empty.", attributeName];
                        break;
                    case NSValidationRelationshipLacksMinimumCountError:  
                        msg = [NSString stringWithFormat:@"The relationship '%@' doesn't have enough entries.", attributeName];
                        break;
                    case NSValidationRelationshipExceedsMaximumCountError:
                        msg = [NSString stringWithFormat:@"The relationship '%@' has too many entries.", attributeName];
                        break;
                    case NSValidationRelationshipDeniedDeleteError:
                        msg = [NSString stringWithFormat:@"To delete, the relationship '%@' must be empty.", attributeName];
                        break;
                    case NSValidationNumberTooLargeError:                 
                        msg = [NSString stringWithFormat:@"The number of the attribute '%@' is too large.", attributeName];
                        break;
                    case NSValidationNumberTooSmallError:                 
                        msg = [NSString stringWithFormat:@"The number of the attribute '%@' is too small.", attributeName];
                        break;
                    case NSValidationDateTooLateError:                    
                        msg = [NSString stringWithFormat:@"The date of the attribute '%@' is too late.", attributeName];
                        break;
                    case NSValidationDateTooSoonError:                    
                        msg = [NSString stringWithFormat:@"The date of the attribute '%@' is too soon.", attributeName];
                        break;
                    case NSValidationInvalidDateError:                    
                        msg = [NSString stringWithFormat:@"The date of the attribute '%@' is invalid.", attributeName];
                        break;
                    case NSValidationStringTooLongError:      
                        msg = [NSString stringWithFormat:@"The text of the attribute '%@' is too long.", attributeName];
                        break;
                    case NSValidationStringTooShortError:                 
                        msg = [NSString stringWithFormat:@"The text of the attribute '%@' is too short.", attributeName];
                        break;
                    case NSValidationStringPatternMatchingError:          
                        msg = [NSString stringWithFormat:@"The text of the attribute '%@' doesn't match the required pattern.", attributeName];
                        break;
                    default:
                        msg = [NSString stringWithFormat:@"Unknown error (code %i).", [error code]];
                        break;
                }

                messages = [messages stringByAppendingFormat:@"%@%@%@\n", (entityName?:@""),(entityName?@": ":@""),msg];
            }
            UIAlertView *alert = [[UIAlertView alloc] initWithTitle:@"Validation Error" 
                                                            message:messages
                                                           delegate:nil 
                                                  cancelButtonTitle:nil otherButtonTitles:@"OK", nil];
            [alert show];
            [alert release];
        }
    }
}

Genießen.

Sicherlich kann nicht sehen, nichts falsch mit diesem code. Wirkt solide. Persönlich bevorzuge ich Griff Core-Daten-Fehler mit einer assertion. Ich habe noch um zu sehen, eine Produktion, so habe ich stets als Entwicklung Fehler anstatt mögliche Fehler in der Produktion. Dies ist zwar sicherlich eine andere Ebene des Schutzes 🙂
Marcus, über Behauptungen: Was ist Ihre Meinung zur Beibehaltung code TROCKENEN in Bezug auf Validierungen? Meiner Meinung nach ist es sehr wünschenswert, definieren Sie Ihre validierungskriterien nur einmal, im Modell (wo es hingehört): Dieses Feld kann nicht leer sein, Feld muss mindestens 5 Zeichen lang und das Feld hat die gleiche regex. Dass sollte werden alle Informationen benötigt, um die Anzeige einer entsprechenden Nachricht an den Benutzer. Es irgendwie nicht gut mit mir zu tun, diese prüft noch einmal im code vor dem speichern des MOC. Was denkst du?
Nie sah diesen Kommentar, da er nicht auf meine Antwort. Sogar, wenn Sie die Validierung der im Modell müssen Sie noch überprüfen, um zu sehen, ob das übergebene Objekt Validierung und präsentieren, dass für den Benutzer. Je nach Ausführung werden könnte, dass auf Feld-Ebene (dieses Passwort ist schlecht, etc.) oder auf dem Punkt zu retten. Designer ' s choice. Würde ich nicht machen, die Teil des app-generic.
Ich Schätze, dass Sie es nie erhielt, weil ich nicht richtig @-Erwähnung Sie 🙂 ich denke, wir sind uns völlig einig: ich würde die Validierung-Informationen werden in das Modell, aber die Entscheidung, Wann trigger überprüfung-und wie zu handhaben und präsentieren das Ergebnis der Validierung sollte nicht generisch sein, und sollten so behandelt werden, an den entsprechenden stellen in den code der Anwendung.
Der code sieht gut aus. Meine Frage ist nur, nach Vorlage der Ausschreibung oder Anmeldung der Analyse, sollte ich ein rollback für die Core Data-Kontext oder einem Abbruch der app? Ansonsten, denke ich, dass die nicht gespeicherte änderungen behalten wird, verursacht das gleiche problem, wenn Sie versuchen, um erneut zu speichern.
Danke! Gut, die NSValidationErrorObject Schlüssel enthält das Objekt, das nicht überprüfen. Wenn irgendein Objekt nicht validieren, speichern wird nicht passieren (die geändert wird nicht auf die Festplatte geschrieben werden). Also je nach app, möchten Sie vielleicht, um den Benutzer aufzufordern, füllen Sie einen gültigen Wert ein, um das problem zu beheben und speichern Sie dann erneut.
Ihre Beratung macht Sinn. Aber, in meinem Fall, die Daten nicht user-gesteuert. Es stammt aus einem server während der Synchronisierung von Daten. So entschloss ich mich, rollback-Kontext, wenn es irgendwelche Fehler beim speichern. Vielen Dank für Ihr Kommentar wenn.
Ah, OK, ich sehe!
es ist schön zu zeigen, wird eine Fehlermeldung, aber das eigentliche problem ist, was zu tun ist über den Kontext der ungültigen Zustand. Während es in diesem Zustand invalid keine Zukunft spart Arbeit, und schlimmer noch, Sie haben nicht einmal ein Fehler gesetzt. cschuff Antwort beginnt zur Bewältigung dieses Problems finden Sie, dass.

InformationsquelleAutor Johannes Fahrenkrug

7

Ich bin überrascht, dass niemand hier ist eigentlich die Handhabung der Fehler, die Art und Weise es zu verstehen ist, behandelt werden. Wenn man sich die Dokumentation, Sie werden sehen.

Typische Gründe für einen Fehler sind hier: * Das Gerät ist aus
Raum. * Der persistent store ist nicht erreichbar, wegen
die Berechtigungen oder den Daten-Schutz, wenn das Gerät gesperrt ist. * Die
store konnte nicht migriert werden, um die aktuelle Modell-version. * Die
übergeordnetes Verzeichnis nicht existiert, kann nicht erstellt werden, oder verweigert
schreiben.

Also wenn ich einen Fehler bei der Einrichtung der core-data-stack, tausche ich den rootViewController des UIWindow und zeigen UI, die eindeutig dem Benutzer mitteilt, dass Ihr Gerät möglicherweise voll oder Ihre Sicherheitseinstellungen sind zu hoch für diese App, um zu funktionieren. Auch ich gebe Ihnen ein 'versuchen Sie es erneut" - Schaltfläche, so können Sie versuchen, das problem zu beheben, bevor der core data stack wieder versucht.

Beispielsweise könnte der Benutzer frei etwas Speicherplatz zurück auf meine App und drücken Sie den button erneut versuchen.

Behauptet? Wirklich? Zu viele Entwickler in den Raum!

Ich bin auch überrascht über die Anzahl von tutorials online, die nicht schweigen, wie ein Speichervorgang fehlschlagen konnte aus diesen Gründen auch. So werden Sie brauchen, um sicherzustellen, dass alle sparen-Ereignis ÜBERALL in Ihrem App könnte scheitern, weil das Gerät GENAU in DIESER MINUTE wurde voll mit Ihren Apps speichern speichern speichern.
- Diese Frage ist über das sparen in der Core-Data-stack, es ist nicht über die Einstellung der Core Data Stack. Aber ich Stimme seiner Titel könnte irreführend sein, und vielleicht sollte es geändert werden.
- Ich Stimme @valeCocoa. Der post ist ganz klar darüber, wie zu handhaben, speichern, Fehler in der Produktion. Nehmen Sie einen anderen Blick.
- das ist, was ich gesagt habe... WtH! 🙂 Nehmen Sie einen anderen Blick auf Ihre Antwort.
- Du bist verrückt, bro
- Sie fügen Teil der Dokumentation für die Fehler, die auftreten können, während der Instanziierung das persistente speichern auf eine Frage bezüglich der Fehler, die beim speichern der Kontext, und ich bin die verrückte? Ok...
- wer kümmert sich, welchen Teil der Dokumentation kommt. es ist immer noch die Wahrheit. sendvid.com/d5u6ikmo
- Nie sagte, es sei nicht wahr, sagte ich, etwas anderes: Sie wurden unter Bezugnahme auf den Teil der Dokumentation, die zu den persistenten store-Initialisierung, Fehler -, und das war das Thema über die Fehlerbehandlung beim speichern der Kontext. Und für die, dass Sie beschlossen, zu schreiben, dass ich verrückt bin... ich denke, wir können hier aufhören, zumindest werden Sie nicht bekommen, jede andere Antwort von mir, auf meinem Teil der Luft wurde gelöscht und ich habe nicht die Absicht, zu Folgen, eine Flamme auf Stack Overflow.
- crazy crazy crazy broooooo
- vielen Dank für eine brillante Idee zu präsentieren, eine neue view-controller. Noch nicht darüber nachgedacht haben!
InformationsquelleAutor
5

Fand ich dieses Allgemeine "speichern" - Funktion eine viel bessere Lösung:
```
- (BOOL)saveContext {
    NSError *error;
    if (![self.managedObjectContext save:&error]) {
        DDLogError(@"[%@::%@] Whoops, couldn't save managed object context due to errors. Rolling back. Error: %@\n\n", NSStringFromClass([self class]), NSStringFromSelector(_cmd), error);
        [self.managedObjectContext rollback];
        return NO;
    }
    return YES;
}
```
, Wenn ein speichern fehlschlägt, wird die rollback-Ihre NSManagedObjectContext Bedeutung, es wird zurückgesetzt alle änderungen, die durchgeführt wurden in dem Zusammenhang die seit dem letzten speichern. So müssen Sie beobachten sorgfältig, um immer bestehen bleiben änderungen, die mit den oben genannten save-Funktion, so früh und regelmäßig wie möglich, da man sonst leicht die Daten verlieren sonst.

Für das einfügen von Daten, könnte dies eine lockerere Variante, dass andere änderungen live auf:
```
- (BOOL)saveContext {
    NSError *error;
    if (![self.managedObjectContext save:&error]) {
        DDLogError(@"[%@::%@] Whoops, couldn't save. Removing erroneous object from context. Error: %@", NSStringFromClass([self class]), NSStringFromSelector(_cmd), object.objectId, error);
        [self.managedObjectContext deleteObject:object];
        return NO;
    }
    return YES;
}
```
Hinweis: ich bin mit CocoaLumberjack für die Anmeldung hier.

Jeder Kommentar auf, wie das zu verbessern ist mehr als willkommen!

BR
Chris
- Ich fühle mich seltsam Verhalten, wenn ich versuche, verwenden Sie das rollback, dies zu erreichen: stackoverflow.com/questions/34426719/...
- Ich bin mit der rückgängig-Funktion statt jetzt
InformationsquelleAutor cschuff

Habe ich eine Swift-version, die nützliche Antwort von @JohannesFahrenkrug, die nützlich sein können :

public func displayValidationError(anError:NSError?) -> String {
    if anError != nil && anError!.domain.compare("NSCocoaErrorDomain") == .OrderedSame {
        var messages:String = "Reason(s):\n"
        var errors = [AnyObject]()
        if (anError!.code == NSValidationMultipleErrorsError) {
            errors = anError!.userInfo[NSDetailedErrorsKey] as! [AnyObject]
        } else {
            errors = [AnyObject]()
            errors.append(anError!)
        }
        if (errors.count > 0) {
            for error in errors {
                if (error as? NSError)!.userInfo.keys.contains("conflictList") {
                    messages =  messages.stringByAppendingString("Generic merge conflict. see details : \(error)")
                }
                else
                {
                    let entityName = "\(((error as? NSError)!.userInfo["NSValidationErrorObject"] as! NSManagedObject).entity.name)"
                    let attributeName = "\((error as? NSError)!.userInfo["NSValidationErrorKey"])"
                    var msg = ""
                    switch (error.code) {
                    case NSManagedObjectValidationError:
                        msg = "Generic validation error.";
                        break;
                    case NSValidationMissingMandatoryPropertyError:
                        msg = String(format:"The attribute '%@' mustn't be empty.", attributeName)
                        break;
                    case NSValidationRelationshipLacksMinimumCountError:
                        msg = String(format:"The relationship '%@' doesn't have enough entries.", attributeName)
                        break;
                    case NSValidationRelationshipExceedsMaximumCountError:
                        msg = String(format:"The relationship '%@' has too many entries.", attributeName)
                        break;
                    case NSValidationRelationshipDeniedDeleteError:
                        msg = String(format:"To delete, the relationship '%@' must be empty.", attributeName)
                        break;
                    case NSValidationNumberTooLargeError:
                        msg = String(format:"The number of the attribute '%@' is too large.", attributeName)
                        break;
                    case NSValidationNumberTooSmallError:
                        msg = String(format:"The number of the attribute '%@' is too small.", attributeName)
                        break;
                    case NSValidationDateTooLateError:
                        msg = String(format:"The date of the attribute '%@' is too late.", attributeName)
                        break;
                    case NSValidationDateTooSoonError:
                        msg = String(format:"The date of the attribute '%@' is too soon.", attributeName)
                        break;
                    case NSValidationInvalidDateError:
                        msg = String(format:"The date of the attribute '%@' is invalid.", attributeName)
                        break;
                    case NSValidationStringTooLongError:
                        msg = String(format:"The text of the attribute '%@' is too long.", attributeName)
                        break;
                    case NSValidationStringTooShortError:
                        msg = String(format:"The text of the attribute '%@' is too short.", attributeName)
                        break;
                    case NSValidationStringPatternMatchingError:
                        msg = String(format:"The text of the attribute '%@' doesn't match the required pattern.", attributeName)
                        break;
                    default:
                        msg = String(format:"Unknown error (code %i).", error.code) as String
                        break;
                    }

                    messages = messages.stringByAppendingString("\(entityName).\(attributeName):\(msg)\n")
                }
            }
        }
        return messages
    }
    return "no error"
}`

InformationsquelleAutor cdescours

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.