3 ms·
I appreciate that. I had never seen that. Of course I've never seen a case where checking for an NSError object failed either. > Although Cocoa methods that in
by mbenjaminsmith 12y ago
I appreciate that. I had never seen that. Of course I've never seen a case where checking for an NSError object failed either.
> 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.
I wish it were a little bit less cryptic. If it's guaranteed then it's guaranteed, no? Is it possible to get a non-nil error object even after a successful call? Is it possible to have the opposite happen? Makes very little sense.
[Edited]
- jurip 12y agoYeah, that's really badly worded. What it's trying to say is that if a Cocoa method has a NSError parameter, it will indicate error state by nil/NO return value. It doesn't say anything about the value of the NSError if the return value is not nil/NO. So for example you could have the out parameter pointing at an existing NSError* at it's possible it will still point there if everything went ok.
- mbenjaminsmith 12y agoI get what you're saying, thanks. I wouldn't ever do that personally, so I guess it's moot.