Handling Errors with responseDecodable

[beninabox]

Absolutely great articles, but I have a question.
It seems that the 'happy path' is handled within the project but I'm wondering how I go about handling an error that is returned from the server.

Let's say, for argument's sake, that there was an implementation that retrieves a specific article from the server, and that the user completes an action that causes a request to get an article from the API that doesn't exist. The server might respond with a 404 status code causing the failure case to get executed instead of success. The server returns an error response in the body, but Alamofire still tries to decode the response into the 'success' model, which it inevitably won't be able to do.

I would assume that creating an error response model would be in order here. Something which again conforms to decodable, but how would that be implemented within performRequest function in our APIClient?

There would, of course, be the case where the error cannot be decoded into the error model, in which case we'd have to handle this separately.

Any ideas?
Thanks!

[abunur]

+1 @beninabox 's comment. If a 401 error is returned this isn't going to be handled by the example code.

[beninabox]

Someone on Stack Overflow pointed me in the right direction with this. Obvious really, now I think about it.
Alamofire will return a failure response because it could not decode the body of the response (not because it was a failure HTTP status code). Therefore we need to also chain the .responseDecodable to .validate(statusCode: 200..<300).

That way, when we get a failure code returned by our server, we can check response.result.isSuccess using a guard statement and if there is a failure, we can handle it from there. My requirement is that the error is decoded, if possible, into a particular error struct I created - so I do that in another method and it is returned as an optional as part of the completion handler. Again to reiterate, with my requirement it may not be possible to decode that error - so I have a generic error response to handle that.

Still need to do some more testing, but it seems to work fairly well for my needs.

I think that handling errors could be explained a little bit in this article. Don't get me wrong, it's a very descriptive and well thought out article, but I think it's important to talk about errors too.

[hoangnguyenvu]

@beninabox same problem with me, how can you solve it, thanks ?

[santhoshs55]

Assume server responds with 200 status code and send some generic error in the response, but Alamofire tries to decode the mentioned object which will fail inevitably so how can we handle this situation?

[karasahinemre]

Someone on Stack Overflow pointed me in the right direction with this. Obvious really, now I think about it.
Alamofire will return a failure response because it could not decode the body of the response (not because it was a failure HTTP status code). Therefore we need to also chain the .responseDecodable to .validate(statusCode: 200..<300).

That way, when we get a failure code returned by our server, we can check response.result.isSuccess using a guard statement and if there is a failure, we can handle it from there. My requirement is that the error is decoded, if possible, into a particular error struct I created - so I do that in another method and it is returned as an optional as part of the completion handler. Again to reiterate, with my requirement it may not be possible to decode that error - so I have a generic error response to handle that.

Still need to do some more testing, but it seems to work fairly well for my needs.

I think that handling errors could be explained a little bit in this article. Don't get me wrong, it's a very descriptive and well thought out article, but I think it's important to talk about errors too.

Can you share an example?

[atifsaeed14]

Just update
request.responseDecodable(decoder: decoder, completionHandler: { (response: AFDataResponse) in
to
request.responseDecodable(decoder: decoder, completionHandler: { (response: DataResponse) in