NSManagedObjectContext save doesn't crash but breaks on objc_exception_throw

I am having the same issue described at this address http://www.cocoabuilder.com/archive/cocoa/288659-iphone-nsmanagedobjectcontext-save-doesn-crash-but-breaks-on-objc-exception-throw.html

I am debugging an application that uses Core Data with multithreading, and I have a breakpoint on objc_exception_throw and it hits this breakpoint in the call to save. (line 2 in code)

        NSError *error = nil;
        [self.managedObjectContext save:&error];
        if (error) {
            NSLog(@"Error : %@",error);
        }

I don't have any thing that is logged. I am using Xcode 4 with ios 4.0 -> 4.3. I think this is 开发者_如何转开发not related to Xcode/iOS version.

---

Looking at this answer reveals that CoreData internally uses exceptions to manage their program flow. Thats why the debugger breaks at objc_exception_throw. As far as I know there is no way to disable this.

EDIT: Since then, there is now a solution to ignore these exceptions: Ignore certain exceptions when using Xcode's All Exceptions breakpoint

BTW: Do not check on error but use the returned BOOL value to ensure success of your save call. The correct way of doing this would be:

NSError *error = nil;
BOOL success = [self.managedObjectContext save:&error];
if (!success) {
    NSLog(@"Error : %@",error);
}

---

• First, when using multithread with CoreData I had few problems when passing NSManagedObject around the app. Instead, as documented by Apple, I end up passing NSManagedObjectID and reconstruct the full object.
• Second, when you don't have anything logged, it is likely related to memory issues, try to run the profiler especially, but not only, looking for 'Zombie', it should tell you more.
• Finally, make sure you have initialized the context correctly, I had similiar problem because the model from momd file was not found and not loaded.

---

I had a similar problem, eventually it turned out to be because of an observer of NSManagedObjectContextDidSaveNotification that was deallocated without removing itself from the notification center. It seems that the CoreData exception "hides" the unknown selector exception that is raised when the notification center tries notifying whatever object occupies the memory freed by the registered (but deallocated) observer.

---

Recently I ran into the same issue: app crashing without any log, when trying to save managedObjectContext.

In my case there was a completely different cause from mentioned above:
Make sure you do not have DB Manager open on your mac, that could be locking the persistent data store.

This will (apparently) also kill the Core Date stack, without throwing any visible errors in code or in log.

Turned out I had some unsaved changes, which made the DB Manager lock the store. Closing the DB Manager fixed the issue. Simple and stupid error, but took me hours to figure out.

---

I happened to meet this problem, and after long time debug I found it's because of a duplicate declaration of the NSError* error, may you had another NSError* error in the outer scope, like:

NSError* error = nil;

Some code

if (!error)
{
    NSError* error = nil;
    // your code
}

Then the error will be nil although in fact there is a exception.