On Mon, 15 Dec 2025 14:26:31 GMT, Christoph Läubrich <[email protected]> wrote:
>> Hello Christoph, >> >>> I think this test assertion alone already shows that a client has only the >>> chance to use String parsing what I think is bad (both for test and for >>> production code). >> >> The API specification of HttpClient for send/sendAsync currently only >> specify IOException with no specific expectations of HTTP protocol specific >> exception types. In several areas of the JDK tests, when necessary, we do >> check the exception messages to be sure that we are testing the right >> failure/exception. Of course, any changes to those internal exception >> messages would require updates to related tests. >> >>> If its not planned to have an own public type, can it at least be an >>> internal exception type that can be used in the test? >> Maybe a Http2ProtocolError? >> >> Your suggestion is valid one . Like Daniel has noted, we do have plans to >> propagate certain HTTP protocol specific error details to the application >> from the HttpClient send/sendAsync APIs, and I think we see the value in >> doing that. It will require specification updates (which is fine) and will >> require some more thoughts on how we want to do it. For example GOAWAY is >> specific to HTTP/2 and HTTP/3 whereas the HttpClient supports HTTP/1.1 too. >> So it will require some thoughts on how we specify such exceptions for these >> APIs. >> >> I will check our JDK issue tracker to see if we have already filed an issue >> for this and if not, I'll file an enhancement and link it here. > >> The API specification of HttpClient for send/sendAsync currently only >> specify IOException with no specific expectations of HTTP protocol specific >> exception types > > Even though its nice do document all possible subtypes I think its not > specifically forbidden (or can be enforced) and there is at least on > precedence with `HttpTimeoutException` (and I can think of many more e.g > EOFException in general) and > `jdk.internal.net.http.common.Utils.toConnectException(Throwable)` even > checks for some of those already (and I see none of those explicitly > documented). > > So I think it not necessarily requires a specification change, for a first > step it could even be non public internal types like > `jdk.internal.net.http.common.ConnectionExpiredException`. Even though there may be some precedents, Internal exception types should not be relayed to user code. In addition introducing new public exception types also introduce new serializable APIs. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28632#discussion_r2619953365
