Is there a better alternative than abort() when moc save fails?
I'm just wondering if there is a better way than killing the app when a moc fails to save. Would it make more sense to call some handler that we can define to maybe mitigate an app crash? I'm not sure exactly what options are available to us in the error object, but it seems that crashing the app is undesirable.
I would like to know more about the conditions that could cause a save to fail. I've always assumed it was related to a programmer error and not a user error. That said, if it dies here it often means something needs to be fixed in code. Can you think of situations or ways of handling it differently?
I'm having the same problems I've described in issue #3 ... one thread deletes the record ... another other one tries to update it ... CoreData can't fulfill a fault so crash ...
IMO, even if the developer made a mistake, the framework should not force the app to quit.
I forked your project to add an error handler...the default implementation will crash as usual, but the developer can set that error handler to ... well ... handle the error. :)
Abort should never be in production code. I thought there was a comment for this but it looks like there isn't. I think you can safely assume the abort should be replaced with something for debugging and any other logic to handle save errors. For instance, I have added some code for recreating a persistent store coordinator in the event that there is a persistent store error.
if ([moc hasChanges] && ![moc save:&error]) {
if([error code] == NSPersistentStoreSaveError)
{
// Kick off a new persistent store
persistentStoreCoordinator = nil;
if([self persistentStoreCoordinator])
{
if([moc hasChanges] && ![moc save:&error])
{
// This is for debug purposes
[self displayValidationError:error];
}
}
}
// This is for debug purposes
[self displayValidationError:error];
}
I'm a little new to Core Data but I think it could be reasonable to add a handler for save errors with some default logic and allow the user to implement it in the case that they need more customization.
Hi @bjtitus: I'm in the process of working with a collaborator to add stronger error handling throughout the library. Have a look at pull request #9. We still need to address the abort() issue (I know this isn't right, but I used to have a different opinion about this). Thanks.