3 ms·

Since Apple advises not to use the error variable for checking for an error, but the return value, I think the decision to have both blocks suits the Obj-C patt

by BSousa 12y ago

Since Apple advises not to use the error variable for checking for an error, but the return value, I think the decision to have both blocks suits the Obj-C patterns a bit more: https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/ErrorHandlingCocoa/CreateCustomizeNSError/CreateCustomizeNSError.html https://developer.apple.com/library/mac/documentation/Cocoa/... (first Important block just down the page)

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 ago
  Yeah, 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 ago
    I get what you're saying, thanks. I wouldn't ever do that personally, so I guess it's moot.
jurip 12y ago
That page doesn't mention blocks at all, though. Apple themselves use the (id value, NSError *error) completion block style with NSURLSession: https://developer.apple.com/library/ios/documentation/Foundation/Reference/NSURLSession_class/Introduction/Introduction.html#//apple_ref/occ/instm/NSURLSession/dataTaskWithURL:completionHandler%3A https://developer.apple.com/library/ios/documentation/Founda... It makes sense with blocks where you have actual multiple values you can pass in without futzing with pointers to pointers.
- mbenjaminsmith 12y ago
  What's strange about that is they don't (at least the few methods that I looked at) define the behavior they're using for "combined" callbacks. Should you check for a non-nil NSError? Is an NSData parameter going to be nil on error?

by BSousa 12y ago

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 ago
Yeah, 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 ago
  I get what you're saying, thanks. I wouldn't ever do that personally, so I guess it's moot.

jurip 12y ago

That page doesn't mention blocks at all, though. Apple themselves use the (id value, NSError *error) completion block style with NSURLSession: https://developer.apple.com/library/ios/documentation/Foundation/Reference/NSURLSession_class/Introduction/Introduction.html#//apple_ref/occ/instm/NSURLSession/dataTaskWithURL:completionHandler%3A https://developer.apple.com/library/ios/documentation/Founda... It makes sense with blocks where you have actual multiple values you can pass in without futzing with pointers to pointers.

mbenjaminsmith 12y ago
What's strange about that is they don't (at least the few methods that I looked at) define the behavior they're using for "combined" callbacks. Should you check for a non-nil NSError? Is an NSData parameter going to be nil on error?