-
Notifications
You must be signed in to change notification settings - Fork 38.4k
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
WebClient: wrap connection exceptions #23842
Comments
Team Decision: It makes sense to handle, wrap and re-emit the different connection exceptions, but doing so will change backwards compatibility and might break users' existing connection-handling code. So we cannot do this until 5.3 at least. As for wrapping in a Finally, I am not so sure if the wrapping and re-throwing pattern is as useful for |
This commit makes sure that exceptions emitted by WebClient are wrapped by WebClientExceptions: - Exceptions emitted by the ClientHttpConnector are wrapped in a new ConnectException. - Exceptions emmitted after a response is received are wrapped in a WebClientResponseException Closes spring-projectsgh-23842
When calling a remote service, it's important to know if an exception happened before sending the request or after receiving the response.
Unfortunately, not all exceptions are wrapped by
WebClientResponseException
,WebClientException
or another subclass ofWebClientException
when callingwebClient.retrieve().bodyToFlux()
resp.webClient.retrieve().bodyToMono()
E.g.:
Before request:
java.net.ConnectException
io.netty.channel.ConnectTimeoutException
io.netty.handler.timeout.ReadTimeoutException
After response:
org.springframework.core.codec.DecodingException
org.springframework.core.codec.CodecException
could happen before request and after response, I guess. How can we detect this?I also might have missed some exceptions.
Exception handling would be much easier if the following rule could be implemented:
if the exception happens after the response -> wrap the exception with a
WebClientResponseException
, so we don't loose the http status code and the payloadelse wrap the exception with a
WebClientException
or another subclass.I'm not sure if this a bug or an enhancement request.
The text was updated successfully, but these errors were encountered: