Kyle
Kyle

Reputation: 17677

NSError** 'Potential null dereference.....'

Giving the following example:

- (BOOL) doSomething: (NSError**) pError
{
    *pError = [NSError ....];
}

Analyzer will return the following error:

Potential null dereference. According to coding standards in 'Creating and Returning NSError Objects' the parameter may be null.

To which the suggestion would be to change this to:

- (BOOL) doSomething: (NSError**) pError
{
    if(pError)
    {
        *pError = [NSError ....];
    }
}

But I would prefer to add a nonnull attribute to the error parameter to discourage the use of passing a null. I cannot figure out how to get the arguments to this correct. Is it possible for a double pointer to have a nonnull attribute?

Upvotes: 2

Views: 564

Answers (1)

matt
matt

Reputation: 534885

But I would prefer to add a nonnull attribute to the error parameter to discourage the use of passing a null.

The syntax you're looking for is shown in various Stack Overflow answers, such as Objective-C nullability for output parameters. So you could declare, for example:

(NSError * _Nullable * _Nonnull)

...and the desired warning would appear:

enter image description here

I would suggest instead, however, that you simply stop preferring that. The analyzer is quite right about the pattern; you should listen to what it's telling you.

The standard full pattern for calling a method that returns NSError by indirection is, for example:

NSString* path = // ... whatever;
NSStringEncoding enc = // ... whatever;
NSError* err = nil;
NSString* s =
    [NSString stringWithContentsOfFile:path encoding:enc error:&err];
if (nil == s) // oops! something went wrong...

But let's say I'm absolutely certain that this is going to work. Then it is legal to say:

NSString* path = // ... whatever;
NSStringEncoding enc = // ... whatever;
NSString* s =
    [NSString stringWithContentsOfFile:path encoding:enc error:nil];

You should not rule this out; it's reasonable and normal.

Upvotes: 4

Related Questions