Add method to ClientResponse that returns Mono terminating with createException

[jwChung]

The method ClientResponse.createException() returns the Mono<WebClientResponseException> type. Mono<Exception> feels like Either<Exception, Exception>. I think that the Mono<RESULT> type is actually needed. So, what if there is the createError method that returns the Mono<RESULT> type in the ClientResponse interface?

[poutsma]

I can see the point for having a different exception, but can't you just map the WebClientResponseException to the type you'd like?

[jwChung]

@poutsma Isn't Mono<T>.onErrorMap/onErrorResume for that?

In many cases, a returning value of createException() is changed to Mono<RESULT> in the following way.

Mono<RESULT> mono = clientResponse.createException().flatMap(e -> Mono.error(new MyException("message", e)));

I wish I could just write it down as the following.

Mono<RESULT> mono = clientResponse.createError().onErrorMap(e -> new MyException("message", e));

[rstoyanchev]

There is a related example in #27645 that doesn't even involve changing the exception. If you use createException from exchangeToMono and exchangeToFlux we have it documented as returning Mono.error(response.createException()) but actually you need response.createException().flatMap(Mono::error) and that's only to be able to match the generic type of the result. It could also be response.createException().cast(...) but either way it's inconvenient.

It would make sense to align createException with Mono#error in terms of being able to cast to anything. After all an error signal switches from some type T to an Exception so this is to be expected. WDYT @poutsma?

[poutsma]

Personally I prefer the explicitness that the Mono<WebClientResponseException> return type offers, as opposed to a generic type. In the latter case, reading the javadoc of the method is pretty much required to see what it does, and that is not true for the former, which pretty much does what you expect from createException.

That said, by looking at #27645, I realise that the current signature is not ideal either and requires the use of a flatMap, which is not obvious. There is no reason against having both createException and createError, so I will add it.