NSError: Does using nil to detect Error actually turn off error reporting?

Question

I got into the habit of coding my error handling this way:

 NSError* error = nil;
 NSDictionary *attribs = [[NSFileManager defaultManager] removeItemAtPath:fullPath error:&error];
 if (error != nil) {
  DLogErr(@"Unable to remove file: error %@, %@", error, [error userInfo]);
  return; 
 }

But looking at the documentation It seems like I got this wrong.:

- (BOOL)removeItemAtPath:(NSString *)path error:(NSError **)error

If an error occurs, upon return contains an NSError object that describes the problem. Pass NULL if you do not want error information.

Technically there is no difference between nil and NULL so does this mean I'm actually turning this off and will never get a error message (even if the delete in the above example did fail) ? Is there a better way to code this ?

Thanks.

There IS difference between `nil` and `NULL`, and `Nil`. `nil` is for instance object, `Nil` is for class object, `NULL` is for any other thing. Since `&error` is memory address, not object, use `NULL` — Philip007, Sep 30 '12 at 22:54

NSGod · Accepted Answer · 2014-05-02T17:42:48.957

First off, the following line doesn't really make sense:

NSDictionary *attribs = [[NSFileManager defaultManager]
 removeItemAtPath:fullPath error:&error];

-removeItemAtPath:error: returns a BOOL value, not a dictionary.

I think I see what you’re wondering about with the NULL value. Notice carefully though, how there are 2 *'s in the error parameter in the method signature:

- (BOOL)removeItemAtPath:(NSString *)path error:(NSError **)error

That means a pointer to a pointer. When you pass in &error, you are passing in the address of the pointer to the NSError. (Ugh, someone else can probably help me out here, as my head still starts to swim when dealing with pointers to pointers). In other words, even though you have set error to nil, you aren't passing in error to the method, you're passing in &error.

So, here’s what the re-written method should look like:

// If you want error detection:
NSError *error = nil;
if (![[NSFileManager defaultManager] removeItemAtPath:fullPath
            error:&error]) {
    NSLog(@"failed to remove item at path; error == %@", error);
    // no need to log userInfo separately
    return;
}

// If you don't:
if (![[NSFileManager defaultManager] removeItemAtPath:fullPath
            error:NULL]) {
    NSLog(@"failed to remove item at path");
    return;
}

Nice catch about the method returning BOOL! I totally missed that. — , Jan 18 '11 at 00:06

score 11 · Answer 2 · 2011-01-18T00:08:39.347

Passing NULL means the following:

BOOL itemRemoved = [[NSFileManager defaultManager] removeItemAtPath:fullPath
    error:NULL];

i.e., the error parameter is NULL. Internally, -removeItemAtPath:error: sees if a valid pointer was passed. If it’s NULL, it simply won’t report the error as an NSError instance — but the return value will indicate whether the method completed successfully.

Also, your test is wrong. You shouldn’t be using the error output parameter to detect if an error occurred because it might be set even if the method completes successfully. Instead, you should use the return value of the method to detect errors. If the return value (in this particular case) is NO, then use the error output parameter to get information about the error:

NSError *error = nil;
BOOL itemRemoved = [[NSFileManager defaultManager] removeItemAtPath:fullPath error:&error];
if (itemRemoved == NO) {
    DLogErr(@"Unable to remove file: error %@, %@", error, [error userInfo]);
    return; 
}

Quoting the Error Handling Programming Guide,

Important: Success or failure is indicated by the return value of the method. Although Cocoa methods that indirectly return error objects in the Cocoa error domain are guaranteed to return such objects if the method indicates failure by directly returning nil or NO, you should always check that the return value is nil or NO before attempting to do anything with the NSError object.

Edit: As NSGod pointed out, -removeItemAtPath:error: returns BOOL, not NSDictionary *. I’ve edited my answer to reflect that as well.

Great Explanation, Thanks a lot. Do you have a short example how the detection code in the call might look like? Is t due to the (NSError **) error declaration that it's possible to differenciate between a pointer to nil and nil ? — EtienneSky, Jan 18 '11 at 00:04
@EtienneSky My answer shows how to detect whether an error occurred by inspecting the return value. NSGod’s answer also does that but without using a variable to store the return value. And yes, `NSError **` allows you to differentiate between a `nil` object (`NSError *`) and a pointer to an `NSError *` object (i.e., `NSError **`), which could be a valid pointer, or `NULL` to indicate there’s no need to store an object in the output parameter. — , Jan 18 '11 at 00:11
I don't think the error object will be set to non-nil if method returns `YES` (complete successfully). The apple doc you quote doesn't mean that way. So checking method return value and checking if `error` is nil should be equivalent. — Philip007, Sep 30 '12 at 23:05

score 0 · Answer 3 · answered Jan 17 '11 at 23:39

No I do it the same way and it works just fine for detecting errors. You are not passing NULL to it you are passing a pointer to NULL to it which is a very different thing. Although another option you might want to add is.

if (error != nil){...
}else{
  [NSApp presentError:error]
}

NSError: Does using nil to detect Error actually turn off error reporting?

3 Answers3

Linked