Hacker News Reader

Comment by mbenjaminsmith | Hacker News Reader

I was hoping to see an integrated completion and error block as I tend to wrap AFNetworking calls to achieve exactly that. I'm sure everyone has their preference but I really like getting everything back in one callback and being able to check for a non-nil error object to handle things accordingly.

I do like the idea of something simpler than AFNetworking though. While AFNetworking is a great library it feels a bit too complex for what it's doing at times. Depending on whether or not I need RestKit in the next project I do I might use this instead of AFNetworking.

Thanks for sharing this.

View on HN

100% yes regarding a single completion/error block. Blocks are verbose at the best of times, and I find having two in the same method is a pain to look at. If there's an error, it's not nil, sorted.

Nothing in AFNetworking forces a success/failure block. For request operations, `completionBlock` can be set directly. For session tasks, the parameter is a `completionHandler`.

I too always end up wrapping AFNetworking calls with an integrated (error, response) block.

I think another wonderful addition would be a client side router to match response serializers with request urls.

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/... (first Important block just down the page)

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]

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.

I get what you're saying, thanks. I wouldn't ever do that personally, so I guess it's moot.

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/Founda...

It makes sense with blocks where you have actual multiple values you can pass in without futzing with pointers to pointers.

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?

Reply on news.ycombinator.com