NSError * returned with bad address - why? - objective-c

Question

In the code below, the NSError, when returned, shows in XCode with a class type of 'HomeViewController' - one of my view controllers. This would make sense if I'd done something out of the ordinary with the double pointer, but I didn't. Why is this happening? Is there some stupid mistake in my code, a bug in Core Data, or ????
Hopefully I'm not making a fool of myself !
self->ctx = [(AppDelegate *) [[UIApplication sharedApplication] delegate] managedObjectContext];
NSFetchRequest * request = [[NSFetchRequest alloc] init];
NSEntityDescription *entityDescription = [NSEntityDescription
entityForName:#"Street" inManagedObjectContext:self->ctx];
NSSortDescriptor* sortDescriptor = [[NSSortDescriptor alloc]
initWithKey:#"street" ascending:YES];
NSArray* sortDescriptors = [[NSArray alloc] initWithObjects: sortDescriptor, nil];
[request setEntity:entityDescription];
[request setSortDescriptors:sortDescriptors];
NSError * error;
NSArray *array = [self->ctx executeFetchRequest:request error:&error];
if(error!=nil){
NSLog(#"%#", #"Critical model error search");
}
_streets = array;

Answer 1

Clearly the method you're using ([self->ctx executeFetchRequest:request error:&error]) doesn't set its argument to nil if there isn't an error, just to the error if one occurs. Initialize your variable to nil: NSError *error = nil;.
As pointed out in the comments, you have to check the return value of the call, and only if it's nil or NO (depending on the declared return type) is the NSError pointer guaranteed valid (incl. nil), even if it was valid going in. So instead of if(error != nil), use if(!array) or if(array == nil).

Answer 2

This keeps coming up. So, some concrete examples.
There is no reason to initialize the NSError to nil. The one caveat is if the object you are calling with the &err is nil, you'll get a false failure and checking an un-initialized error will blow up. However, that failure mode is very different than an attempt that leads to failure and, really, you should avoid the nil recipient case (imagine if your managed object context is unexpectedly nil-- you probably have a much bigger issues than a false error).
This is a perfectly valid implementation of a method that returns BOOL and takes an NSError**. Valid, but obviously contrived. However, this kind of thing does happen in a many layered API.
- (BOOL)doThis:(NSError**)chaffin
{
if (chaffin) *chaffin = 0x42;
return YES;
}
Calculating the error can be expensive. Pass null for the error parameter if you only need to know success/failure, but not why.