AFNetworking/AFNetworking — pull request #2252 by mrackwitz (2014-08-18 17:56:35+00:00)
Title: Make error accessible on AFNetworkingOperationDidFinishNotification

If you observe `AFNetworkingOperationDidFinishNotification` for a `AFHTTPRequestOperation`, and the operation fails because of an serialization error (e.g. an unexpected status code), you won't be able to detect this by checking the operation's error property. This is valid as this is the intended behavior of the API.

This effects some special cases, for example AFNetworking/AFNetworkActivityLogger/issues/14.
(I have seen the related and closed issue #1968, and similars like #1876.)

But currently there are only some rather ugly ways to workaround this:
* call `[operation responseObject]`, which will initialize the object as a side-effect.
* do not rely on notifications only (e.g. use in combination `dispatch_notify` and a custom `completionGroup`), but this has in any case side-effects to the operation.

Without neccessary hurting the current API contract (which possibly depends on interpretation), there would be also the following solutions:

1. Ensure that it was tried once to deserialize the response, when `error` is called.
- Add a new method (e.g. `[operation errorEnsureResponseDeserializationWithCompletionBlock:]`) where the same as in the previous suggestion would be done, but with a block-based interface as this call could otherwise led into blocking the main thread with an expensive deserialization operation. This would ensure furthermore full backwards-compatibility.

This PR goes solution proposal number 1 and make the side-effect from responseObject *less* transparent.