If a Java::JavaNet::SocketTimeoutException is thrown while connecting in JRuby it's currently re-raised as a generic OpenSSL::SSL::SSLError, instead of as a HTTPClient::TimeoutError. This is because SocketTimeoutException is a subclass of IOException, and thus this gets covered by the generic IOException handling (https://github.com/nahi/httpclient/blob/master/lib/httpclient/jruby_ssl_socket.rb#L495). It's useful to handle TimeoutExceptions differently (CircuitBreaker pattern, in my case), so I'd like to break this handling out. This will ALSO help avoid a JRuby bug that this triggers (jruby/jruby#3834) where this wrapped exception is then turned into an anonymous exception.
If a Java::JavaNet::SocketTimeoutException is thrown while connecting in JRuby it's currently re-raised as a generic OpenSSL::SSL::SSLError, instead of as a HTTPClient::TimeoutError. This is because SocketTimeoutException is a subclass of IOException, and thus this gets covered by the generic IOException handling (https://github.com/nahi/httpclient/blob/master/lib/httpclient/jruby_ssl_socket.rb#L495). It's useful to handle TimeoutExceptions differently (CircuitBreaker pattern, in my case), so I'd like to break this handling out. This will ALSO help avoid a JRuby bug that this triggers (jruby/jruby#3834) where this wrapped exception is then turned into an anonymous exception.