Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Can I safely wrap 'CoreData could not fulfill a fault' errors in a @try catch block

Tags:

ios

core-data

I understand why this error happens: when you try to access a CoreData object that was deleted in a managed object context on another thread, and is hence set to a 'fault' object, and any retained references will therefore no longer point to a valid CoreData object.

I am using a NSFetchedResultsController.

I have confirmed that all the code is implemented correctly. I have 2 managed object contexts, one intended for a BG thread and one for the main thread.

I have confirmed that the main thread is subscribed for notifications under NSManagedObjectContextDidSaveNotification.

I have confirmed that when this notification fires, I perform a mergeChangesFromContextDidSaveNotification: on the main thread managed object context.

I am NOT retaining these objects anywhere, but I am setting the batch size for the NSFetchRequest (Is this potentially the issue?)

YET, I still occasionally get the 'CoreData could not fulfill a fault' error.

In my particular application, this usually happens during a sort of "data-bind" process so I could safely just discard fault objects and move on. I would like to do this by wrapping the inside of the loop that data-binds in a @try-catch block and just skip rows that I get the CoreData error for.

Can I safely do this with CoreData? Or do I need to completely dump the managed object context after I encounter a fault.

I did check this question about how to check if a CoreData object is a fault, which might be something I implement if I can't safely assume that my @try-catch block won't cause other issues.

like image 347
eanticev Avatar asked Jan 29 '13 19:01

eanticev


1 Answers

Instead of using try-catch we can use "existingOjectWithId" and check for nil on returned object.

- (NSManagedObject*)existingObjectWithID:(NSManagedObjectID*)objectID error:(NSError**)error 

The above returns the object for the specified ID if it is already registered in the context, or faults the object into the context. If the object cannot be fetched, or does not exist, or cannot be faulted, it returns nil. Unlike -objectWithID: it never returns a fault.

like image 115
Sandy Avatar answered Nov 03 '22 19:11

Sandy