Wrap DecodingException thrown by WebFlux functional endpoints

[bclozel]

In Spring WebFlux, reading an invalid request body can result in a DecodingException thrown by the codec.

In the annotation variant, this exception is wrapped in a ServerWebInputException in ArgumentResolver implementations. Since ServerWebInputException extends ResponseStatusException, this is automatically handled by the error handling mechanism as an HTTP 400 response status.

Right now in the functional variant, the DecodingException bubbles up and causes an HTTP 500 error since it's not expected by the error handling infrastructure.

The DecodingException Javadoc mentions:

For example in server web application, a DecodingException would
translate to a response with a 400 (bad input) status while
CodecException would translate to 500 (server error) status.

@poutsma, I think we should align WebFlux functional with the annotation variant here; doing so in BodyExtractors is not the right choice since this class can be used on both server and client side.
Since this behavior is expected by the error handling infrastructure, should we introduce this exception mapping in HandlerFunctionAdapter? Or is there a better place for that?

[poutsma]

If we do it in the adapter then the error handling will not apply in "standalone" mode (i.e. using RouterFunctions.toWebHandler and not the DispatcherHandler). I am thinking that DefaultServerRequest.bodyInternal is a better place, as that's used by all body variants.