views:

80

answers:

1

Example: I have an Cat entity with an catAge attribute. In the data modeler, I configured catAge as int with a max of 100. Then I do this:

[newManagedObject setValue:[NSNumber numberWithInt:125] forKey:@"catAge"];

// Save the context.
NSError *error = nil;
if (![context save:&error]) {
    NSLog(@"Unresolved error %@, %@", error, [error userInfo]);
}

I'm getting an error in the console, like this:

2010-06-12 11:40:41.947 CatTest[2250:207] Unresolved error Error Domain=NSCocoaErrorDomain Code=1610 UserInfo=0x10164d0 "Operation could not be completed. (Cocoa error 1610.)", {
    NSLocalizedDescription = "Operation could not be completed. (Cocoa error 1610.)";
    NSValidationErrorKey = catAge;
    NSValidationErrorObject = <NSManagedObject: 0x10099f0> (entity: Cat; id: 0x1006a90 <x-coredata:///Cat/t3BCBC34B-8405-4F16-B591-BE804B6811562> ; data: {
    catAge = 125;
    catName = "No Name";
});
    NSValidationErrorPredicate = SELF <= 100;
    NSValidationErrorValue = 125;
}

Well, so I have an validation error. But the odd thing is, that it seems the MOC is broken after this. If I just tap "add" to add another invalid Cat object and save that, I'm getting this:

2010-06-12 11:45:13.857 CatTest[2250:207] Unresolved error Error Domain=NSCocoaErrorDomain Code=1560 UserInfo=0x1232170 "Operation could not be completed. (Cocoa error 1560.)", {
    NSDetailedErrors =     (
        Error Domain=NSCocoaErrorDomain Code=1610 UserInfo=0x1215f00 "Operation could not be completed. (Cocoa error 1610.)",
        Error Domain=NSCocoaErrorDomain Code=1610 UserInfo=0x1209fc0 "Operation could not be completed. (Cocoa error 1610.)"
    );
}

That seems to report two errors now. BUT: When I try to delete now an valid, existing object from the table view (using the default core data template in a navigation-based app), then the app crashes! All I get in the console is:

2010-06-12 11:47:18.931 CatTest[2250:207] Unresolved error Error Domain=NSCocoaErrorDomain Code=1560 UserInfo=0x123eb30 "Operation could not be completed. (Cocoa error 1560.)", {
    NSDetailedErrors =     (
        Error Domain=NSCocoaErrorDomain Code=1610 UserInfo=0x1217010 "Operation could not be completed. (Cocoa error 1610.)",
        Error Domain=NSCocoaErrorDomain Code=1610 UserInfo=0x123ea80 "Operation could not be completed. (Cocoa error 1610.)"
    );
}

...so no idea where or why it crashes, but it does. So the question is, what are the neccessary steps to take when there's an validation error?

+3  A: 

The crash you are experiencing is probably not related to the previous errors, but without the relevant source code this is almost impossible to tell. Anyway, in order to deal correctly with the situation you describe, you have two alternatives. You can either report the error to the user, so that he/she can modify the offending value violating the validation check and then save the context, or you must delete from the context the NSManagedObject.

There is an overall better strategy. Instead of letting Core Data apply automatically validation before saving the context (using either automatically generated methods or your own methods), do yourself a validation test before taking an action. Do this using the NSManagedObject methods

- (BOOL)validateForInsert:(NSError **)error;
- (BOOL)validateForUpdate:(NSError **)error;
- (BOOL)validateForDelete:(NSError **)error;

If these methods return YES, you can proceed. Otherwise, as before alert the user and let him/her modify the object as needed or delete the object. The difference with respect to the previous situation is that in this case you have not saved the context. You save the context only when the previous methods return YES, so you are sure that saving will succeed.

unforgiven
+1 As well, when it is important, I call the validation methods for properties in a custom setter and pass it the input before setting. That lets you back out immediately if you encounter an issue.
TechZen
Actually I do exactly the same: as you pointed out, IMHO is preferable to backtrack immediately and alert the user before saving the data.
unforgiven
That's an great idea. When it comes to validation in every setter, I'd be cautious because of performance. In some situations I could imagine that it's not good to validate on every set. Can't think of a good example right now, but maybe a color picker that constantly analyzes the selected color and sees if it matches against the CI color palette over the network.
dontWatchMyProfile