Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to handle 422 json error response? #69

Open
sjmueller opened this issue Nov 21, 2022 · 4 comments
Open

How to handle 422 json error response? #69

sjmueller opened this issue Nov 21, 2022 · 4 comments
Labels
Milestone

Comments

@sjmueller
Copy link

Our api server gives a 422 response when validating request params:

{
    "errors": [{ "detail": "Missing field: anon_id" }]
}

However, Get only supplies the error code: Response status code was unacceptable: 422 via APIError

.unacceptableStatusCode(let statusCode)

How can we hook into the actual error response for logging and (sometimes) showing to the user?

@kean
Copy link
Owner

kean commented Nov 21, 2022

You can throw a custom error by implementing client(_:validateResponse:data:task:).

It might be worth also expanding unacceptableStatusCode and adding response Data and URLResponse for convenience.

@kean kean added the question Further information is requested label Nov 21, 2022
@sjmueller
Copy link
Author

Thanks @kean, client(_:validateResponse:data:task:) is useful for the scenario of logging all error messages, bug reporting, etc.

I think you're on to something by expanding Data / URLResponse, because api.send catch block would be the ideal place to surface validation errors to the user.

@kean
Copy link
Owner

kean commented Nov 23, 2022

Thanks @kean, client(_:validateResponse:data:task:) is useful for the scenario of logging all error messages, bug reporting, etc.

It is also designed for providing a way to generate custom errors instead of Get.APIError. The APIs typically use the same error model across the endpoints, hence the centralized place for parsing them. But if the error models are different, it's not ideal, yes.

@kean kean added feature and removed question Further information is requested labels Nov 23, 2022
@kean kean added this to the 3.0 milestone Dec 17, 2022
@kean
Copy link
Owner

kean commented Feb 22, 2023

I'm prototyping an improved version of async API for Get 3.0 to address Xcode 14.3 warnings.

I think it'll work nicely for decoding custom errors.

let dataTask = await client.dataTask(with: Request<User>(path: "/user"))

if #available(iOS 15, *) {
    for await progress in dataTask.progress.values {
        print(progress)
    }
}

do {
    let response = try await dataTask.response.value
} catch {
    let data = try await dataTask.data
    // Parse error
}

It could probably be improved further. Currently, if the server responds with 422, the entire Response is lost which is not ideal because you might need any of this information, even in case of a failure – as you pointed out. If I go in this direction, the response getter becomes non throwing, which I think will be ideal.

let response = await dataTask.response

do {
    let value = try await response.value // Decodes the value
} catch {
   // Catch all errors here
   if let data = response.data {
      // You change to parses data
   }
}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants