managedObjectContext save fails with error being null

Question

What would cause an error to come back null, this is what I have

    + (BOOL)saveContext:(NSManagedObjectContext *)context
    {
      NSError *error = nil;
      if (![context save:&error]) 
      {
        DLog(@"ERROR %@, %@", error, [error userInfo]);
        UIAlertView *alert = [[UIAlertView alloc] initWithTitle:@"Sorry"

                                                        message:@"Error Saving the Data" 
                                                       delegate:nil 
                                              cancelButtonTitle:@"OK"
                                              otherButtonTitles:nil];

        [alert show];
        [alert release];

        return NO;
      }
    return YES;
    }

The above method is a class method, I am not sure why the error does not have any information.

This method is called like this

[HSCoreDataUtility saveContext:self.managedObjectContext];

when a modalViewController is closing and returning to the NavigationController, so I need the context to be saved, but it throughs an error, now I think I have an idea as to the cause of it not being saved, but shouldn't the error give me a clue? but the log just says "ERROR (null), (null)"

any thoughts

Outsider

Are you sure context is non-nil? – Disengage

Answer 1

Only way I can see that situation happening is if you are passing in a nil context. I would put a logic bomb at the top of that class method to guard against that.

Well, actually, I wouldn't create a class method for this small amount of code; but the point still stands. Check for a nil context.

Semite

the context is not nil, i know this for sure – Outsider

i am how ever passing the context around, it starts in the app delegate and I pass it around from there, could that have anything to do with it. – Outsider

It may be getting released somewhere, or not retained? Have it spit out the current [context retainCount] with a nil check. It never hurts to check. – Accelerometer

never use retainCount, ever. Do an NSAssert check against nil at the top of the method. – Semite

The context being nil was exactly my problem, thanks for the tip! – Animation

Answer 2

I lived your pain and end up surviving. ;)

After long debugging time I realized in custom object validation method, in some cases I was returning NO and not initializing an error.

If you have this problem check validation object methods. That probably was your problem as well.

Bonehead

That may not have been the original poster's problem, but this is exactly what happened to me. Thanks! Seems like Core Data should throw an exception rather than contradict the NSManagedObjectContext documentation -- I should file a bug. – Religion

This deserves 10 up votes. This saved me hours of hair pulling, I'm sure! Agreed, it's probably not the original problem, but it certainly occurs with the exact same symptoms. – Distraint

Oh my God! I'd spend hours to figure this out. Thanks! – Brookins

Thanks! Also spend hours on it... until finding your hint. – Bellow

Answer 3

This is a really old thread, but hopefully my response helps someone who finds this on Google like I did. I was running into this same problem and none of these answers were my problem; it turns out I made the very boneheaded, silly mistake of not deleting/reinstalling the app when I changed the data model, so the save was failing without an error. Check to make sure you don't do the same thing! :)

Berylberyle

Answer 4

Uhm, I'm not sure %@ will cause the error to go verbose. [error localizedDescription] ?

Accelerometer

i have used both, [error userInfo] and [error localizedDescription], same thing error (null), (null) – Outsider

Answer 5

I happened to meet this problem, and after long time debug I found it's because of a duplicate declaration of the NSError* error, may you had another NSError* error in the outer scope, like:

NSError* error = nil;

// some code

if (!error)
{
    NSError* error = nil;

    // your code
}

Then the error will be nil although in fact there is an exception.

Stratify