Feature: Ability to decode error response about papyrus

[F0x1d]

I can relate. Now we have to completely manually do Response parsing if we want to get the body of error response. I suggest passing ErrorResponse with PapyrusError as it is done in Retrofit.

In my perfect world I see it this way:

try {
    return try await someAPI.generate()
} catch error as PapyrusError {
    var message = error.message
    
    if let someError = try? error.response.body?.decode(SomeError.self, using: jsonDecoder) {
        message = someError.messageFromServerDescribingError
    }
    
    // show message to user
}

[ucomah]

For the cases I met, used an additional interceptor which decodes specific API error responses. If it fails - default error processor will be used.

let authIterceptor = AuthRequestInterceptor(verifier: authVerifier, updater: authUpdater)
let durationInterceptor = RequestDurationInterceptor()
let authModifier = AuthRequestModifier(authStore: store)

let defaultProvider = Provider(baseURL: API_BASE_URI, 
                               modifiers: [authModifier],
                               interceptors: [APIErrorInterceptor(), authIterceptor, durationInterceptor])

[joshuawright11]

Thanks for the feedback @malonehedges!

What's the use case you're thinking of?

Using the body from the raw Response is currently the only way. The error might not have a body (i.e. if there were a transport error) and having a custom error type on an unsuccessful status code would be tricky to have it built in. You'd need to have two types in the return; an expected Res type plus the possible Err type to decode.

You are able to use the build in decode(...) function on Response however:

@GET("/error")
func getError() async throws -> Response

let res = try await api.getError()
if let statusCode = res.statusCode, !(200...399).contains(statusCode) {
    let errorBody = try res.decode(MyCustomErrorResponse)
    // handle custom error response
} else {
    // handle success
}

[malonehedges]

In my APIs I typically return either 200 with the expected response type, or some error code and { "error": true, "message": "Handle must be between 4 and 16 characters" } for example, so that I can show that message in the client

[malonehedges]

Ultimate goal is to turn a fetch failure into a message, either defined by the API in the response or falling back to "Something went wrong, please try again"

[joshuawright11]

Thanks @F0x1d for the PR 💯

This is released as of v0.6.2.