Adding SocketChannel toString to connection exception messages

Bernd Eckenfels ecki at
Fri Dec 22 16:42:45 UTC 2017


I also dearly miss Socket addresses in connection exceptions, however it looks like it is not going to make it. However if we add a getter for the Peer address (not included in toString) then logging frameworks could detect instances of ConnectException and process them accordingly.

From: net-dev <net-dev-bounces at> on behalf of Chris Hegarty <chris.hegarty at>
Sent: Friday, December 22, 2017 4:17:31 PM
To: Seán Coffey; David Holmes; Steven Schlansker
Cc: core-libs-dev; net-dev at
Subject: Re: Adding SocketChannel toString to connection exception messages

On 22/12/17 14:59, Seán Coffey wrote:
> As someone who works with alot of log files, I'd like to chime in and
> support Steven's end goal. Looking at a "Connection refused" error in
> the middle of a log file that possibly extends to millions of lines is
> near useless. In the era of cloud compute, diagnosing network issues is
> sure to become a more common task.
> While we may not be able to put the sensitive information in an
> exception message, I think we could put it behind a (new?) system
> property which might be able to log this information. Logs contain all
> sorts of sensitive data. Take output for example.

I have some sympathy for (capital-L)ogging such detail messages
( given the reasonable restriction on access to log files ), but
a system property that effectively amends exception detail
messages, or prints to stdout/stderr is not a runner in my

Maybe we should be looking at instrumentation with JFR events, or
similar. My point being, if someone has time and energy enough
to spend on this, then we can do better than
Also, someone should check that divulging such sensitive information,
even in log files, is acceptable from a security perspective. I'm
personally still dubious.


More information about the core-libs-dev mailing list