JEP-353 - Socket.connect now throws NoRouteToHostException as against ConnectException previously

[Alan Bateman]

On 21/08/2021 08:17, Jaikiran Pai wrote:
> JEP-353[1] which got implemented and released in JDK13, states:
>
> "The java.net package defines many sub-classes of SocketException. The 
> new implementation will attempt to throw the same specific 
> SocketException as the old implementation but there may be cases where 
> they are not the same."
>
> In one of the projects I watch, a recent issue[2] shows that the 
> "Socket.connect(...)" call, in certain cases, now throws a 
> "java.net.NoRouteToHostException" exception as opposed to 
> "java.net.ConnectException" in previous versions before this change. 
> The "Socket.connect(...)" javadoc states that this API can throw an 
> "IOException", so this change, in theory, is still fine and doesn't 
> break any API contract. However, as noted in [2], certain libraries 
> (Apache HTTP client 4.5.x versions in this case) expect a certain 
> exception type when it's dealing with decision making for HTTP request 
> retries. Due to this change in the exception type being thrown, the 
> Apache HTTP client library now behaves differently in Java 11 and Java 
> 16.
>
> Is this change of exception type being thrown intentional? Or is there 
> interest in changing back to the previous exception type to preserve 
> backward compatibility? If not, I think the Apache HTTP client library 
> will have to perhaps do certain changes to have this part of the code 
> behave the same across Java versions.

Thanks for the mail, I haven't seen any other reports on this.

Can you say which operating system and say a bit more about the 
conditions where this is observed? When connecting to a host that is not 
reachable then it's possible for the underlying connect to fail with a 
"Connection timed out", "No route to host", or other errors.

The reason I'm asking about the OS/conditions is that the old 
implementation did attempt to map specific errors to 
NoRouteToHostException. There's an example stack stack (Windows, with 
JDK 9) in this bug report:
   https://bugs.openjdk.java.net/browse/JDK-8042714

In general, the mapping of connect errors to sub-classes of 
SocketException has always been best effort and I both both 
ConnectException and NoRouteToHostException are possible, all depends on 
the underlying error.

So my initial reaction is that we shouldn't do anything right now, I 
think we need to know a bit more abut the environment/conditions as I'm 
puzzled as to why the HTTP client retry decision didn't run into this 
before with the old implementation.

-Alan