On 29 Jan 2016, at 12:21, Riccardo Mottola <riccardo.mott...@libero.it> wrote: > > 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.
It would help to look at the code in question. I suspect it’s to do with the fact that, with ARC, pointers to objects are implicitly cleared on creation, because every object pointer must either be nil or a valid object. David -- Sent from my Apple II _______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
