feature: Do not throw exception when status code is not 200

[andrew-vdb]

Is your feature request related to a problem? Please describe.

We would like refit to not throw exception when response status code is not 200 Api may response with status code 400 and return the error message etc According the best practices https://docs.microsoft.com/en-us/aspnet/core/performance/performance-best-practices?view=aspnetcore-6.0

Describe the solution you'd like

RefitSetting boolean, do not throw when status code is not 200

Describe alternatives you've considered

SonarQube complaining about this and I'm not quite sure with the risk of this code

Describe suggestions on how to achieve the feature

RefitSetting boolean, do not throw when status code is not 200

Additional context

I'm not the first one who request this issue, the work around still throw exception but we just don't provide the handling? Don't see why its difficult to implement this feature

[DouglasKSmith]

Have you considering making your Refit interface methods return Task<IApiResponse>, Task<IApiResponse<T>>, or Task<ApiResponse<T>>? This would cause non-successful responses to be populated as an ApiException into the ApiResponse.Error property without being thrown.

[andrew-vdb]

Yes, changing signature feels like a bit overkill

The main point is there is no exception 400 is also valid successful response as the server successfully responding the client Exception should be used when there is real exception like the server is not responding (with timeout) but that's my opinion so....

We could simply make a change here https://github.com/reactiveui/refit/blob/92ee8887fce181f211cb7ca1e7f8d8c7afa0a821/Refit/ApiResponse.cs

[andrew-vdb]

Another argument is that calling this method is fully optional to the caller

EnsureSuccessStatusCode

[HelloKitty]

Did anything like this end up getting implemented? I'd love to be able to have refit try to deserialize the body by default on all response codes and only throw if it cannot.

[anaisbetts]

I think the current behavior is as intended, if users want custom error handling there is a mechanism to do so.

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.