2

My question is similar to this one, but I need further clarification. I often get exceptions during code like this:

NSError* error;
if (![managedObjectContext save:&error]) {
    NSLog(@"Failed to save to data store: %@", [error localizedDescription]);
}

However, when I put a breakpoint in objc_exception_throw, I can find out that an exception is thrown in save:

(gdb) po [$eax name]
NSInternalInconsistencyException
(gdb) po [$eax description]
optimistic locking failure

I wouldn't expect this, since the docs say that an optimistic locking failure will return an error, not an exception.

As an aside, I can't even seem to catch this exception with @try ... @catch (NSException * e) in the code. It's all strange.

Community
  • 1
  • 1
sehugg
  • 3,615
  • 5
  • 43
  • 60

1 Answers1

2

I think what's happening is that objc_exception_throw is catching internal exceptions in Core Data, but they really aren't percolating to my app. Because I set my merge policy, the locking failures are getting converted into object merges and all is well.

I should probably also use committedValuesForKeys: so I can see what's going on before the exceptions .. this doesn't happen every time.

sehugg
  • 3,615
  • 5
  • 43
  • 60
  • Don't forget to accept your own answers if they solve the issue. – Marcus S. Zarra Jan 11 '10 at 01:52
  • Looking into a similar issue myself. It does seem that the exception is thrown internally but is resolved by the merge policy: if I use a general exception breakpoint I catch the exception on the background context's thread. However, if I set another breakpoint after the save operation I can see that the save return `YES` and the error is `nil`... As such it would *seem* to be a non-issue. I hope so anyway! – Jonathan Crooke Mar 06 '14 at 09:28