NSError as parameter to methods

[Riccardo Mottola]

Hi,

yesterday while debugging some mac code written by others, I found that 
the programmer implied that if there is an error, NSError return value 
contains an error, but if everything was OK, it would be nil.

|- (BOOL)writeToFile:(NSString 
<https://developer.apple.com/library/mac/documentation/Cocoa/Reference/Foundation/Classes/NSString_Class/index.html#//apple_ref/doc/c_ref/NSString> 
*)|/path
/|             options:(NSDataWritingOptions 
<https://developer.apple.com/library/mac/documentation/Cocoa/Reference/Foundation/Classes/NSData_Class/#//apple_ref/doc/c_ref/NSDataWritingOptions>)|/mask
/|               error:(NSError 
<https://developer.apple.com/library/mac/documentation/Cocoa/Reference/Foundation/Classes/NSError_Class/index.html#//apple_ref/doc/c_ref/NSError> 
* _Nullable *)|/errorPtr/||

eg:

[obj doSomething: &error];
if (error) NSLog(@"error")

would always work. This is not how some of our methods in NSData appear 
to work.
A conservative way of interpreting things is: If there is an error, I 
give you back an error, if not I leave your variable "as is", maybe with 
the previous error. Thus, one needs to init it to nil for example before 
passing it.
Or, otherwise check for error only if the method returns NO (supposing).

I think the GS implementation is perfectly sound. I wonder if Apple is 
overzeaulous and "nils out" or instead the code works on the mac because 
the compiler initialized error to nil and just it worked "by chance" 
becuse it is the first usage.

What's your take?

Riccardo