NSManagedObjectContext: exception breakpoint stops on save: method, but no log / failure / error

Question

I use CoreData in a multi-threaded iOS application, and everything seems to work fine - unless I turn on the exception checkpoint in Xcode. Whenever I do some work with CoreData, the breakpoint stops at the save: method on the NSManagedObjectContext , but NSError is nil afterwards. I also have nothing in the log (except: Catchpoint 2 (exception thrown). ), The application does not crash ... So it's pretty hard to say what is going wrong.

The only key I have is that I have one object in updatedObjects: in my NSManagedObjectContext , but there is nothing wrong with it.

My question is very similar to https://stackoverflow.com/a/3129609/129231 ... but the only answer does not help me; I am pretty sure that everything is covered there.

What could be wrong here? Or are there other options for getting error information?

Thank you very much!

EDIT : showing the code is pretty hard. I load objects using objectID, edit and save them in the context assigned to the current thread. I already checked - the context is always correct for the current thread; each thread has its own context, which should not be a problem. It would even be helpful if someone could tell me how to get more information from this error / exception - or if I still need to do this. It seems to me that the exception falls into the "save" method, so maybe this is the "normal" behavior?

Answer 1

This is normal behavior. CoreData uses exception throwing and handling internally for some part of its program flow. I spoke about this with the people of CoreData. It may seem strange, but it is a design decision that they made a long time ago.

When you get into the exception, make sure that none of your codes in the return channel between your call -[NSManagedObjectContext save:] and the exception being thrown. Calling -save: will most likely call you back in your code, for example. if you observe NSManagedObjectContextObjectsDidChangeNotification , and if you do bad things when working with this notification, it is obvious that you are mistaken.

If you exit the -save: method and the return value is YES , everything will be fine.

Note that you must check the return value, do not use error != nil to check for errors. Correct check:

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

Answer 2

You can avoid these useless breaks; as others have pointed out, this is normal CoreData behavior (but very annoying!)

• Remove Checkpoint "All Objective-C Exceptions"
• Add a symbolic breakpoint to objc_exception_throw
• Set the condition for the breakpoint to (BOOL)(! (BOOL)[[(NSException *)$eax className] hasPrefix:@"_NSCoreData"])
• I would also like to add the action, debugger, "po $ eax" command, which usually prints exception details

$ eax is the correct register for the simulator, $ r0 works on devices. You can create two separate breakpoints and enable / disable them as needed.

See Ignore some exceptions when using the Xcode All Exceptions breakpoint for the original response.

Answer 3

I had a similar problem. In the end, I realized the problem:

I added an observer to NSManagedObjectContextDidSaveNotification , which was released without being removed from the notification center. When its memory was tied to another object, the notification center tried to call this object and threw an exception because it could not find the correct selector. For some reason, this exception was "invisible", but forced CoreData to create its own exception.

A well-established call to removeObserver: fixed the problem.

Hope this helps someone else who is facing this situation.

Answer 4

I had a similar problem in my code. Finally, I found that the problem was changing my model, and the EncryptedCoreData NSPersistentStoreCoordinator I used was not configured for automatic migration, as I expected in MagicalRecord in the past.

The only symptom was this breakpoint without any other messages. It was solved (temporarily) by uninstalling and reinstalling the application and permanently adding the model versions and the corresponding key ( NSMigratePersistentStoresAutomaticallyOption: true, NSInferMappingModelAutomaticallyOption: true ) to my stack setup.