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:47:50 -0400
On Jun 8, 2010, at 1:24 PM, David Brown wrote:
> Have you thought about avoiding the problem altogether?
>
> Instead of marking the objects and then needed to save them, write out a file somewhere that identifies those objects, outside of core data.
>
> Then, when your app is starting, check for the presence of the file before anything else happens, and take whatever actions you need to take to resume the processing.
That's certainly a possible workaround. Core Data should be able to handle this though. When I relaunch my app, all the changes did propagate properly. Everything works in the Distribution build without warnings, errors, etc. It's just that objc_exception_throw gets called, and I'm wondering why. Is it a symptom of an unrelated problem that I'm not understanding yet, is it a bug in Core Data, or should I just not worry about it?
Hank
>>> 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
>
>
_______________________________________________
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