Mike Abdullah

Prompted by a friend's tweet (sorry it's late Kevin!) I was reminded of the code we've implemented to make life more pleasant when Core Data throws an error your way.

Problem 1: The alert sheet doesn't reveal enough detail

It's understandable; your customers don't care which bit of the model failed validation, they want a more helpful answer supplied by the application – or even better the error not to occur in the first place! But what about you, how do you dig into the error for more detail?

One option is to place a breakpoint on -[NSApp willPresentError:]. From there, introspect the error object in the debugger.

But this is somewhat of a pain. Getting hold of the error object in the debugger is tricky for a start! Somewhat more palatable is to log such errors to the console (probably for debug builds only, but up to you).

A nice convenient location is your app delegate:

- (NSError *)application:(NSApplication *)theApplication
        willPresentError:(NSError *)error
{
    // Log the error to the console for debugging
    NSLog(@"Application will present error:\n%@", [error description]);
    return error;
}

Problem 2: There's no easy way to see the entirety of an error's contents

The above snippet uses the built-in -[NSError description] method. It's pretty informative, but Core Data has a tendency to construct several, nested error objects. Particularly if there are multiple validation errors. Try this little beauty out in a category on NSError:

- (NSString *)debugDescription;
{
    //  Log the entirety of domain, code, userInfo for debugging.
    //  Operates recursively on underlying errors
    NSMutableDictionary *dictionaryRep = [[self userInfo] mutableCopy];
    [dictionaryRep setObject:[self domain]
                      forKey:@"domain"];
    [dictionaryRep setObject:[NSNumber numberWithInteger:[self code]]
                                                  forKey:@"code"];
    NSError *underlyingError = [[self userInfo] objectForKey:NSUnderlyingErrorKey];
    NSString *underlyingErrorDescription = [underlyingError debugDescription];
    if (underlyingErrorDescription)
    {
        [dictionaryRep setObject:underlyingErrorDescription
                          forKey:NSUnderlyingErrorKey];
    }
    // Finish up
    NSString *result = [dictionaryRep description];
    [dictionaryRep release];
    return result;
}

Did you know that when you do po foo in the debugger, the string printed is actually generated by calling -[foo debugDescription]? So this neatly means that po error will give you better results.

And of course, you'll want to change the error presentation snippet at the top of the page to log using -debugDescription.

NSArrayController is quite possibly one of the most useful classes in Cocoa; it applies to so much situations in a modern application. Quite often you may need to subclass it to customise some aspect of the behaviour.

In particular, overriding -insertObject:atArrangedObjectIndex: is particularly handy. I use it regularly with Core Data so that inserting a managed object updates some kind of index attribute for sorting objects by. The documentation is on your side here, calling out the reason to override this method.

But what if you need to customise the behaviour when removing objects too? In the example above you could use it to update the index attribute of any remaining objects. Or your controller might be managing some unusual kind of relationship where removing an object requires extra work such as deleting unused objects.

If so, the docs are no longer on your side. No indication is given how you might do this – although there is a helpful note about the behaviour of -removeObject: with Core Data. Unsatisfied (yes, I filed rdar://7447617), I was forced to seek the answer by trial and error. So without further ado, here's the solution. Some simple drop-in code for your own custom classes:

@implementation MYArrayController
- (void)willRemoveObject:(id)object;
{
    // Put your removal handling code here
}
- (void)removeObjects:(NSArray *)objects
{
    // -removeObject: calls this method internally.
    // Iterate the objects, reporting each one
    for (id anObject in objects)
    {
        [self willRemoveObject:anObject];
    }
    [super removeObjects:objects];
}
- (void)removeObjectAtArrangedObjectIndex:(NSUInteger)index
{
    // -removeObjectsAtArrangedObjectIndexes: calls this repeatedly
    id object = [[self arrangedObjects] objectAtIndex:index];
    [self willRemoveObject:object];
    [super removeObjectAtArrangedObjectIndex:index];
}
@end