I'm not sure if this is intended behavior or not. When making a request and the endpoint has an invalid SSL certificate, an HttpRequestException is thrown. The documentation states:
To encapsulate any exceptions that may come from a service, you can catch an ApiException which contains request- and response information. Refit also supports the catching of validation exceptions that are thrown by a service implementing the RFC 7807 specification for problem details due to bad requests. For specific information on the problem details of the validation exception, simply catch ValidationApiException
This implies that there is no need to catch HttpRequestException. I think, if this is intended behavior, the docs could be improved. If it's unintended behavior, then it's a bug.
In either case, I'm willing to submit a pull request if you can point me in the right direction.
I wasn't aware that it had been documented like that, because ApiException doesn't wrap many other HttpRequestExceptions, including DNS issues, etc.
I think it would be great if it did though.
I wasn't aware that it had been documented like that, because
ApiExceptiondoesn't wrap many otherHttpRequestExceptions, including DNS issues, etc.I think it would be great if it did though.
I took a look at the source. It appears this is probably intended behavior. Personally, either way doesn't matter to me. I just want to know what exceptions I need to catch. Because this library wraps HttpClient, it's not obvious what exceptions you need to catch unless you want to look at implementation details. I suspect a simple update to the docs making it clear that you still need to catch HttpRequestException would go a long way.
There could be a more general RefitException class that gets inserted underneath ApiException, where we could have catch/wrap other exceptions and provide a common base exception type.
Would having a simple ErrorHandlingHttpClientMessageHandler implementation suffice?
public class ErrorHandlingHttpClientMessageHandler : DelegatingHandler
{
protected override Task<HttpResponseMessage> SendAsync(HttpRequestMessage request, CancellationToken cancellationToken) {
try {
return base.SendRequest(request, cancellationToken);
} catch (HttpRequestException reqErr) {
// log error
// rethrow or handle it accordingly as you see fit
}
}
}
Closing due to age. Please try Refit v6 and reopen if still an issue.
Most helpful comment
Would having a simple
ErrorHandlingHttpClientMessageHandlerimplementation suffice?