Include request/response details in mapped error, when possible #1803
Conversation
|
@sadlerjw why not just use |
|
@segiddins I don't think there is an underlying error in this case. Happy to be proven wrong though :) |
| @@ -263,3 +263,4 @@ | |||
| @see `RKErrorMessage` | |||
| */ | |||
| NSError *RKErrorFromMappingResult(RKMappingResult *mappingResult); | |||
| NSError *RKErrorFromMappingResultAndRequestResponse(RKMappingResult *mappingResult, NSURLRequest *request, NSHTTPURLResponse *response); | |||
There was a problem hiding this comment.
make this a static method internal to the .m
There was a problem hiding this comment.
I'd argue that this new function should be called generally instead of RKErrorFromMappingResult. In fact, I suggest that we deprecate RKErrorFromMappingResult and keep the new function listed here as a public function.
Alternatively, if you want to discourage people from calling these functions, we could make the new one private, as you suggest, and deprecate the old function.
If you are opposed to these suggestions, I'll go ahead and implement your original idea - just wanted to suggest a possible alternative.
There was a problem hiding this comment.
we could make the new one private, as you suggest, and deprecate the old function
👍
|
Rebase this onto development and I'll merge it |
When a non-200-series HTTP status code is received and there is no object mapping set up to handle it, an NSError is generated that includes the response string, the request's URL, and the request and response objects themselves. This allows consumers of RestKit to inspect these objects (for instance, to find out the status code) in order to determine the correct course of action. (See RKHTTPRequestOperation's `error` method) When an object mapping does exist for non 200-series status codes, the mapped error does not include this information - it only includes the mapped error(s) and a localized description. This leaves RestKit consumers no idea of what the HTTP status code was, which is usually important information when determining how to react to an error. This commit adds URL, request, and response to the NSError object, but does not add responseString, because the same information is conveyed by the mapped error object(s). We maintain backwards compatibility by using `nil` for request and response when using the old function.
|
Updated |
|
Just realized this never got test coverage :/ If you add that, I can merge. |
Summary
This allows RestKit consumers to perform an error mapping on the response, but still inspect the HTTP status code of the response, or any other properties of the request and response objects.
Details
When a non-200-series HTTP status code is received and there is no object mapping set up to handle it, an
NSErroris generated that includes the response string, the request's URL, and the request and response objects themselves. This allows consumers of RestKit to inspect these objects (for instance, to find out thestatus code) in order to determine the correct course of action. (See
RKHTTPRequestOperation'serrormethod)When an object mapping does exist for non 200-series status codes, the
NSErrorobject does not include this information - it only includes the mapped error(s) and a localized description. This leaves RestKit consumers no idea of what the HTTP status code was, which is usually important information when determining how to react to an error.This commit adds URL, request, and response to the
NSError'suserInfo, but does not addresponseString, because the same information is conveyed by the mapped error object(s) (which are stored inuserInfo[RKObjectMapperErrorObjectsKey].We maintain backwards compatibility by implementing this functionality in a new function, which is invoked using
nilforrequestandresponsewhen the old function is called. (There are no internal calls to the old function, but it is listed in a.hfile so some RestKit consumers may be calling it.)