iPhone Core Data "Production" Error Handling
No one is going to show you production code because it depends 100% on your application and where the error occurs.
Personally, I put an assert statement in there because 99.9% of the time this error is going to occur in development and when you fix it there it is highly unlikely you will see it in production.
After the assert I would present an alert to the user, let them know an unrecoverable error occurred and that the application is going to exit. You can also put a blurb in there asking them to contact the developer so that you can hopefully track this done.
After that I would leave the abort() in there as it will "crash" the app and generate a stack trace that you can hopefully use later to track down the issue.
This is one generic method I came up with to handle and display validation errors on the iPhone. But Marcus is right: You'd probably want to tweak the messages to be more user friendly. But this at least gives you a starting point to see what field didn't validate and why.
- (void)displayValidationError:(NSError *)anError {
if (anError && [[anError domain] isEqualToString:@"NSCocoaErrorDomain"]) {
NSArray *errors = nil;
// multiple errors?
if ([anError code] == NSValidationMultipleErrorsError) {
errors = [[anError userInfo] objectForKey:NSDetailedErrorsKey];
} else {
errors = [NSArray arrayWithObject:anError];
}
if (errors && [errors count] > 0) {
NSString *messages = @"Reason(s):\n";
for (NSError * error in errors) {
NSString *entityName = [[[[error userInfo] objectForKey:@"NSValidationErrorObject"] entity] name];
NSString *attributeName = [[error userInfo] objectForKey:@"NSValidationErrorKey"];
NSString *msg;
switch ([error code]) {
case NSManagedObjectValidationError:
msg = @"Generic validation error.";
break;
case NSValidationMissingMandatoryPropertyError:
msg = [NSString stringWithFormat:@"The attribute '%@' mustn't be empty.", attributeName];
break;
case NSValidationRelationshipLacksMinimumCountError:
msg = [NSString stringWithFormat:@"The relationship '%@' doesn't have enough entries.", attributeName];
break;
case NSValidationRelationshipExceedsMaximumCountError:
msg = [NSString stringWithFormat:@"The relationship '%@' has too many entries.", attributeName];
break;
case NSValidationRelationshipDeniedDeleteError:
msg = [NSString stringWithFormat:@"To delete, the relationship '%@' must be empty.", attributeName];
break;
case NSValidationNumberTooLargeError:
msg = [NSString stringWithFormat:@"The number of the attribute '%@' is too large.", attributeName];
break;
case NSValidationNumberTooSmallError:
msg = [NSString stringWithFormat:@"The number of the attribute '%@' is too small.", attributeName];
break;
case NSValidationDateTooLateError:
msg = [NSString stringWithFormat:@"The date of the attribute '%@' is too late.", attributeName];
break;
case NSValidationDateTooSoonError:
msg = [NSString stringWithFormat:@"The date of the attribute '%@' is too soon.", attributeName];
break;
case NSValidationInvalidDateError:
msg = [NSString stringWithFormat:@"The date of the attribute '%@' is invalid.", attributeName];
break;
case NSValidationStringTooLongError:
msg = [NSString stringWithFormat:@"The text of the attribute '%@' is too long.", attributeName];
break;
case NSValidationStringTooShortError:
msg = [NSString stringWithFormat:@"The text of the attribute '%@' is too short.", attributeName];
break;
case NSValidationStringPatternMatchingError:
msg = [NSString stringWithFormat:@"The text of the attribute '%@' doesn't match the required pattern.", attributeName];
break;
default:
msg = [NSString stringWithFormat:@"Unknown error (code %i).", [error code]];
break;
}
messages = [messages stringByAppendingFormat:@"%@%@%@\n", (entityName?:@""),(entityName?@": ":@""),msg];
}
UIAlertView *alert = [[UIAlertView alloc] initWithTitle:@"Validation Error"
message:messages
delegate:nil
cancelButtonTitle:nil otherButtonTitles:@"OK", nil];
[alert show];
[alert release];
}
}
}
Enjoy.
I'm surprised no one here is actually handling the error the way it is meant to be handled. If you look at the documentation, you will see.
Typical reasons for an error here include: * The device is out of space. * The persistent store is not accessible, due to permissions or data protection when the device is locked. * The store could not be migrated to the current model version. * The parent directory does not exist, cannot be created, or disallows writing.
So if I find an error when setting up the core data stack, I swap the rootViewController of UIWindow and show UI that clearly tells the user that their device might be full, or their security settings are too high for this App to function. I also give them a 'try again' button, so they can attempt to fix the problem before the core data stack is re-attempted.
For instance the user could free up some storage space, return to my App and press the try again button.
Asserts? Really? Too many developers in the room!
I'm also surprised by the number of tutorials online that don't mention how a save operation could fail for these reasons also. So you will need to ensure that any save event ANYWHERE in your App could fail because the device JUST THIS MINUTE became full with your Apps saving saving saving.
I found this common save function a much better solution:
- (BOOL)saveContext {
NSError *error;
if (![self.managedObjectContext save:&error]) {
DDLogError(@"[%@::%@] Whoops, couldn't save managed object context due to errors. Rolling back. Error: %@\n\n", NSStringFromClass([self class]), NSStringFromSelector(_cmd), error);
[self.managedObjectContext rollback];
return NO;
}
return YES;
}
Whenever a save fails this will rollback your NSManagedObjectContext meaning it will reset all changes that have been performed in the context since the last save. So you have to watch out carefully to always persist changes using the above save function as early and regularly as possible since you might easily lose data otherwise.
For inserting data this might be a looser variant allowing other changes to live on:
- (BOOL)saveContext {
NSError *error;
if (![self.managedObjectContext save:&error]) {
DDLogError(@"[%@::%@] Whoops, couldn't save. Removing erroneous object from context. Error: %@", NSStringFromClass([self class]), NSStringFromSelector(_cmd), object.objectId, error);
[self.managedObjectContext deleteObject:object];
return NO;
}
return YES;
}
Note: I am using CocoaLumberjack for logging here.
Any comment on how to improve this is more then welcome!
BR Chris
I've made a Swift version of the useful answer of @JohannesFahrenkrug which can be useful :
public func displayValidationError(anError:NSError?) -> String {
if anError != nil && anError!.domain.compare("NSCocoaErrorDomain") == .OrderedSame {
var messages:String = "Reason(s):\n"
var errors = [AnyObject]()
if (anError!.code == NSValidationMultipleErrorsError) {
errors = anError!.userInfo[NSDetailedErrorsKey] as! [AnyObject]
} else {
errors = [AnyObject]()
errors.append(anError!)
}
if (errors.count > 0) {
for error in errors {
if (error as? NSError)!.userInfo.keys.contains("conflictList") {
messages = messages.stringByAppendingString("Generic merge conflict. see details : \(error)")
}
else
{
let entityName = "\(((error as? NSError)!.userInfo["NSValidationErrorObject"] as! NSManagedObject).entity.name)"
let attributeName = "\((error as? NSError)!.userInfo["NSValidationErrorKey"])"
var msg = ""
switch (error.code) {
case NSManagedObjectValidationError:
msg = "Generic validation error.";
break;
case NSValidationMissingMandatoryPropertyError:
msg = String(format:"The attribute '%@' mustn't be empty.", attributeName)
break;
case NSValidationRelationshipLacksMinimumCountError:
msg = String(format:"The relationship '%@' doesn't have enough entries.", attributeName)
break;
case NSValidationRelationshipExceedsMaximumCountError:
msg = String(format:"The relationship '%@' has too many entries.", attributeName)
break;
case NSValidationRelationshipDeniedDeleteError:
msg = String(format:"To delete, the relationship '%@' must be empty.", attributeName)
break;
case NSValidationNumberTooLargeError:
msg = String(format:"The number of the attribute '%@' is too large.", attributeName)
break;
case NSValidationNumberTooSmallError:
msg = String(format:"The number of the attribute '%@' is too small.", attributeName)
break;
case NSValidationDateTooLateError:
msg = String(format:"The date of the attribute '%@' is too late.", attributeName)
break;
case NSValidationDateTooSoonError:
msg = String(format:"The date of the attribute '%@' is too soon.", attributeName)
break;
case NSValidationInvalidDateError:
msg = String(format:"The date of the attribute '%@' is invalid.", attributeName)
break;
case NSValidationStringTooLongError:
msg = String(format:"The text of the attribute '%@' is too long.", attributeName)
break;
case NSValidationStringTooShortError:
msg = String(format:"The text of the attribute '%@' is too short.", attributeName)
break;
case NSValidationStringPatternMatchingError:
msg = String(format:"The text of the attribute '%@' doesn't match the required pattern.", attributeName)
break;
default:
msg = String(format:"Unknown error (code %i).", error.code) as String
break;
}
messages = messages.stringByAppendingString("\(entityName).\(attributeName):\(msg)\n")
}
}
}
return messages
}
return "no error"
}`