Adding SocketChannel toString to connection exception messages

Seán Coffey sean.coffey at
Fri Dec 22 14:59:42 UTC 2017

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.


On 22/12/17 09:57, Chris Hegarty wrote:
> On 22/12/17 01:27, David Holmes wrote:
>> cc'ing net-dev as that might be the more appropriate list.
>> On 22/12/2017 10:59 AM, Steven Schlansker wrote:
>>>> On Dec 21, 2017, at 4:35 PM, David Holmes <david.holmes at> 
>>>> wrote:
>>>> On 22/12/2017 10:29 AM, Steven Schlansker wrote:
>>>>>> On Dec 21, 2017, at 11:11 AM, Steven Schlansker 
>>>>>> <stevenschlansker at> wrote:
>>>>>> What if ConnectException included the attempted hostname / IP / 
>>>>>> port SocketAddress?
>>>>>> Connection to 
>>>>>> '[10.x.x.x]:12345' refused
>>>>>> Much more useful!  This could also be extended to various other 
>>>>>> socket exceptions.
>>>> I believe there are concerns with too much information that can be 
>>>> considered "sensitive" (like host names and IP addresses) appearing 
>>>> in error messages due to them ending up in log files and bug reports.
>>> Unfortunately that's exactly the information that is crucial to 
>>> someone trying to diagnose issues...
> And to someone trying to discern private information about a network.
>>> Could it be an opt-in policy?  Perhaps by a system property?
> Well, you don't know where a log file or exception will end up.
> Most likely on stackoverflow.
>> The expectation is that such information should be added by layers 
>> higher in the call chain, rather than the JDK libraries assuming it 
>> is okay to do.
> Agreed. It may be some work, but if the issue is significant
> enough to the user then it may be worth their effort, as well
> as affording the opportunity to opt-out at any particular
> point in the code.
>>> Currently the alternative I'm faced with is going through every 
>>> piece of user code and library that *might*
>>> throw this exception and wrapping it to add this critical diagnostic 
>>> information.  For an application that uses
>>> heavily, you can imagine how that is a tall task and 
>>> possibly even not realistically achievable...
>>> (Is there a written policy regarding this somewhere, or is it up to 
>>> the personal feelings of the contributors?)
>> This is covered by the secure coding guidelines, under 'Confidential 
>> information':
>> "Guideline 2-1 / CONFIDENTIAL-1: Purge sensitive information from 
>> exceptions"
> Exactly.
>> I know for a fact that we'd have to scrub this information from test 
>> failures when putting the info into a bug report.
>> If net-dev folk can't expand further on this then I suggest filing a 
>> CSR request so that the CSR group can consider it. But I think this 
>> will be a no-go (I'm a member of the CSR group).
> I have to agree with David here. I don't think that such a request
> could be supported.
> -Chris.

More information about the core-libs-dev mailing list