Affects: 5.3.10 (and previous)
ExchangeFunctions.wrapException() is called when the following predicate evaluates as true:
t -> !(t instanceof WebClientException) && !(t instanceof CodecException);
This predicate will return true on any java.lang.Error instance such as OutOfMemoryError, causing the error to be wrapped inside a WebClientRequestException.
Given that throwing an unhandled Error can cause the JVM to shutdown, allow developers to add hooks to them, etc. I'm just wondering if this predicate should evaluate as false when an Error is thrown.
Comment From: jhoeller
Such wrapping of Throwable is not just there in ExchangeFunctions but in several other places as well, including the MVC DispatcherServlet for many years already. We have not seen any negative impact of such wrapping, and no difference in terms of the JVM's state afterwards. JVM shutdown hooks etc nevertheless apply, not being bound to propagation of the raw Error.
In many cases, OutOfMemoryError may even be recoverable, e.g. if some request handler failed to allocate a very large array for a specific request, with other request processing still continuing side by side. Wrapping such an error in a common container exception allows exception handlers to kick in, rather than everything getting bypassed and application-level state (including thread-local state) immediately becoming inconsistent. If the JVM itself is unstable at that point, we may not be able to fully clean up for the given request, but we're at least trying (and arguably not making things worse through such an attempt).
Comment From: rubasace
Thanks for the informative response, that actually makes sense.
Closing the ticket as it doesn't seem like an issue to me anymore.