Re: [iPhone] NSManagedObjectContext save doesn't crash but breaks on objc_exception_throw
Re: [iPhone] NSManagedObjectContext save doesn't crash but breaks on objc_exception_throw
- Subject: Re: [iPhone] NSManagedObjectContext save doesn't crash but breaks on objc_exception_throw
- From: "Hank Heijink (Mailinglists)" <email@hidden>
- Date: Tue, 8 Jun 2010 13:16:19 -0400
There's no error or log at all, unless I set the merge policy to the default, in which case the error parameter contains what I expect it to contain: a conflict list with the right objects and properties that I expect to be in conflict. I understand the error coming back from the save, but not the call to objc_exception_throw.
In case it matters, this is on iPhone OS 3.1.3, Xcode 3.2.2.
Thanks,
Hank
On Jun 8, 2010, at 12:08 PM, Alexander Spohr wrote:
> Is there anything in the log?
> What does save's error parameter return?
>
> atze
>
>
> Am 08.06.2010 um 17:53 schrieb Hank Heijink (Mailinglists):
>
>> Dear all,
>>
>> I've run into the following problem, and I'm a bit stuck - I wonder if you can shed some light on this. I have an iPhone app that uses Core Data, and the problem occurs when the app terminates. I have an NSOperationQueue with potentially several NSOperations that are cancelled in the applicationWillTerminate: UIApplication delegate method.
>>
>> These NSOperations all have their own copy of an NSManagedObjectContext and an NSManagedObject subclass (I pass them the persistent store coordinator and an NSManagedObjectID that is permanent at that point).
>>
>> Canceling the NSOperation changes an attribute of the NSManagedObject subclass and I save the NSManagedObjectContext on the background thread after this change is made. This means that the NSManagedObjectContext on the main thread is now in conflict, and since all this happens in applicationWillTerminate:, it won't receive the NSManagedObjectContextDidSaveNotification so it can deal with it.
>>
>> My solution to this is to set the merge policy to NSMergeByPropertyStoreTrumpMergePolicy right before saving the main NSManagedObjectContext to give precedence to the already-saved context(s). I haven't been able to find any information about this scenario - the Core Data Programming Guide (in Communicating Changes Between Contexts) seems to suggest my approach (case 3b), although there in-memory changes are preferred over store changes.
>>
>> I always have a break point set on objc_exception_throw, and it hits this breakpoint in the call to save. This is the stack backtrace:
>>
>> #0 0x986d94e6 in objc_exception_throw ()
>> #1 0x01dee37c in -[NSPersistentStoreCoordinator(_NSInternalMethods) executeRequest:withContext:] ()
>> #2 0x01e22afe in -[NSManagedObjectContext save:] ()
>> #3 0x000036b6 in -[MyAppDelegate applicationWillTerminate:]
>> ...<snip>...
>>
>> However, if I remove the break point or hit continue, the application quits with an exit code of 0. If I wrap my [NSManagedObjectContext save] call in a @try @catch block, the @catch statements are never executed. So, is there an exception or isn't there? Should I rethink my approach? I'm just not sure what the issue is here.
>>
>> Any information is greatly appreciated!
>>
>> Thanks in advance,
>> Hank_______________________________________________
>>
>> Cocoa-dev mailing list (email@hidden)
>>
>> Please do not post admin requests or moderator comments to the list.
>> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>>
>> Help/Unsubscribe/Update your Subscription:
>>
>> This email sent to email@hidden
>
>
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden