NSManagedObjectContext: exception point d'arrêt s'arrête à enregistrer: méthode, mais aucun journal/panne/erreur

Question

Je suis l'aide de CoreData dans un environnement multi-thread iOS-app, et tout semble bien fonctionner - à moins que je passe sur l'exception de point d'arrêt dans XCode. Chaque fois que je fais un peu CoreData-travail, le point d'arrêt s'arrête à l' save:-méthode d' NSManagedObjectContext - mais le NSError est nul par la suite. J'ai aussi rien dans le journal (à l'exception de: Catchpoint 2 (exception thrown).), l'application ne plante pas... Donc c'est assez difficile de dire ce qui ne va pas.

Le seul indice que j'ai c'est que j'ai un objet unique en updatedObjects: mon NSManagedObjectContext - mais il semble y avoir rien de mal avec elle.

Ma question est très similaire à cette question sur stackoverflow mais la seule réponse ne m'aide pas; je suis sûr que j'ai tout ce qui y sont traitées.

Ce qui pourrait être mal ici? Ou existe-il d'autres possibilités pour obtenir quelques informations sur l'erreur?

Merci beaucoup!

EDIT: en affichant le code est assez difficile. Je suis le chargement des objets avec objectID, de les éditer et de les stocker dans le cadre assigné pour le thread courant. J'ai déjà vérifié - le contexte est toujours correct pour le thread en cours; chaque thread a son propre contexte, qui ne devrait pas être le problème. Il serait même utile si seulement quelqu'un pouvait me dire comment faire pour obtenir plus d'informations sur cette erreur/exception - ou si j'ai des soins à ce sujet, après tout. Il me semble que si l'exception est piégé à l'intérieur de la `save-méthode, et c'est probablement son un comportement "normal"?

Answer 1

C'est normal de comportement. CoreData utilise exception de jeter et de manutention, en interne, pour certains de ses flux de programme. J'ai parlé à la CoreData les gens à ce sujet. Il peut sembler étrange, mais c'est une conception de la décision qu'ils ont prise il y a longtemps.

Quand vous frappez l'exception, assurez-vous il n'y a pas de code dans le backtrace entre votre appel à l' -[NSManagedObjectContext save:] et de l'exception levée. Appelant -save: est très susceptible d'appel dans votre code, par exemple si vous êtes en observant NSManagedObjectContextObjectsDidChangeNotification, et si vous faites de mauvaises choses lorsque vous êtes la manipulation de ceux de notification, de toute évidence, vous êtes en faute.

Si vous êtes à la sortie de l' -save: méthode, et la valeur de retour est - YES, tout est bon.

Veuillez noter que vous devez vérifier la valeur de retour, ne pas utiliser error != nil pour vérifier la présence d'une erreur. Le chèque correct est:

NSError *error = nil;
BOOL success = [moc save:&error];
if (!success) {
    // do error handling here.
}

Answer 2

Vous pouvez éviter ces pauses inutiles; comme d'autres l'ont souligné, cela est normal CoreData comportement (mais très ennuyeux!)

1. Supprimer le "Tous Objective-C Exceptions" point d'arrêt
2. Ajouter une Symbolique point d'arrêt sur objc_exception_throw
3. Définir une Condition sur le point d'arrêt (BOOL)(! (BOOL)[[(NSException *)$eax className] hasPrefix:@"_NSCoreData"])
4. Je tiens à ajouter une action, d'une commande de débogueur, "po $eax", qui imprime généralement les détails de l'exception

$eax est le registre pour le simulateur, $r0 fonctionne sur les appareils. Vous pouvez créer deux points d'arrêt et d'activer/de désactiver au besoin.

Voir Ignorer certaines exceptions lors de l'utilisation de Xcode de Toutes les Exceptions point d'arrêt pour l'original de la réplique

Answer 3

J'ai eu un problème similaire. Finalement, j'ai compris le problème:

J'ai ajouté un observateur à NSManagedObjectContextDidSaveNotification qui l'a libéré sans suppression de lui-même depuis le centre de notification. Lorsque sa mémoire a obtenu attribué à un autre objet, le centre de notification essayé d'appeler sur cet objet et a soulevé une exception, car il ne pouvait pas trouver la droite du sélecteur. Cette exception a été "invisible" pour une raison quelconque, mais il a provoqué CoreData pour augmenter sa propre exception.

Bien placé removeObserver: appel fixe le problème.

Espérant que cela puisse aider quelqu'un d'autre qui est confronté à cette situation.