On Wed, 30 Jul 2025 09:33:29 GMT, Volkan Yazici <[email protected]> wrote:
>> test/jdk/java/net/httpclient/FileChannelPublisherTest.java line 513:
>>
>>> 511: LOGGER.log("Verifying the client failure");
>>> 512: Exception requestFailure =
>>> assertThrows(ExecutionException.class, () -> responseFutureRef.get().get());
>>> 513: assertInstanceOf(UncheckedIOException.class,
>>> requestFailure.getCause());
>>
>> I think the application should be receiving a `IOException` (both for send()
>> and sendAsync()) instead of a `UncheckedIOException`.
>
> The `IOE` thrown is wrapped by an `UncheckedIOE` in
> `FileChannelIterator::next`, which overrides `Iterator::next` and that does
> not allow a `throws` in the `next()` footprint. Would you mind elaborating on
> your remark, please?
Hello Volkan, the specification of `HttpClient.send(...)` (and sendAsync()) is
that it throws a checked `IOException`. So any other exceptions that we throw
internally (like this one) need to be converted to an `IOException` when it
reaches the application code.
We have code in `HttpClientImpl.send(...)` which currently does instanceof
checks against these exceptions and converts them to an `IOException`. I'm
guessing your test is currently passing, which suggests to me that
`sendAsync()` is propagating a `UncheckedIOException` to the application code.
Would it be possible to tweak the test a bit to replace that call of
`sendAsync()` with a `send()` (even if those tweaked changes cannot be pushed
to this PR) and see what gets propagated? I suspect it would be `IOException`.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/26155#discussion_r2242150036
