Reputation: 4214
I am working on an app for some time, nearly ready for release. I have never addressed any of the error handling in core data fetches, haven't really ever had an error in that regard. All my fetches are populated with the standard:
if (fetchedObjects == nil)
{
// Handle Error, or Not
}
Maybe some have an abort in there left over from the startup template. What is the best practice recommendation for handling this and similar errors throughout my project? Can I make one distinct method to put in all of these or do I have to decide on case by case basis.
Upvotes: 2
Views: 280
Reputation: 8570
for a start if fetchedObjects are nil there might not have been an error. You should be checking the error directly. Read up on NSError if needed
If (error){
//handle error here...
<#statements#>
//return early if this is going to cause a crash
return;
}
Heres a list of all the possible coreData error codes: https://developer.apple.com/library/mac/#documentation/Cocoa/Reference/CoreDataFramework/Miscellaneous/CoreData_Constants/Reference/reference.html
Pare down which ones you will be using, for example if you're not using validation you will never get validate errors.
Then I would create a general use class that handles some of the more disasterous ones. They're never likely to happen, but if they do your best option is to display a message to the user that something bad has happened and ask them to delete and re-install the app. (or write some reset code if thats not too difficult for your implementation).
Then at each error point there may be some specific errors you want to handle differently. As you'll be looking at each error point in your code anyway to remove those abort() calls this analysis will fit into your process easily.
Usually if core data produces an error on fetch on the iPhone something disastrous has happened. If you get an error saving or inserting data then you can try to figure out why and if worst comes to worst throw away changes, after telling the user what to expect. If its unacceptable to throw away changes (e.g. if you are storing documents for the user or other user created data) the you have more work to do to figure out the problem. The most likely save error will be running out of disk space.
Upvotes: 2