On Thu, 16 Oct 2025 11:37:16 GMT, Daniel Fuchs <[email protected]> wrote:
>> Although it might look strange - we might want to wrap the
>> UncheckedIOException instead of peeling it off.
>> If the UncheckedIOException is generated by us (HttpClient implementation)
>> then we most likely want to peel it off. But if it originates from custom
>> code, peeling it off might hide important stack trace information.
>> I am actually hesitating between the two possibilities.
>>
>> We see here that peeling of the UncheckedIOException from within sendAsync
>> forces you to modify one test, where the UncheckedIOException was
>> originating from custom code. I am not 100% sure we want do that.
>>
>> On the other hand - we don't want to add yet another version of
>> toIOException.
>>
>> Let me think about this a bit more.
>
> OK - I think what you have is fine. Let's peel of UncheckedIOException. In
> most cases I could see the UncheckedIOException is only used to smugle an
> IOException, and in most case it's created at the point where the IOException
> is created too. That let me think that the extra stack trace will not be
> needed in most of the cases. We could revisit possibly later in a followup if
> we have reason to...
I think, not propagating the original `UncheckedIOException` would be a bug.
Imagine this application code:
final Future<HttpResponse<String>> future = client.sendAsync(req, new
BodyHandler<String>() {
@Override
public BodySubscriber<String> apply(ResponseInfo ri) {
throw new UncheckedIOException("application specific message", new
IOException("some other message"));
}
});
final HttpResponse<String> resp;
try {
resp = future.get();
} catch (ExecutionException e) {
final Throwable cause = e.getCause();
// cause must be UncheckedIOException and its message must be "application
specific message"
assert ...
}
I think the application should receive the `UncheckedIOException` as the top
level cause of the `ExecutionException` and that `UncheckedIOException` must
contain the original cause and the original message that was there when the
application raised it. Not passing along that to the application, I think,
would be wrong.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/27787#discussion_r2451852130
