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
_______________________________________________
Gnustep-dev mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/gnustep-dev
