Adding SocketChannel toString to connection exception messages

[Peter Levart]

Hi Steven,

Steven Schlansker je 02. 01. 2018 ob 22:25 napisal:
>> On Jan 2, 2018, at 8:35 AM, Alan Bateman<Alan.Bateman at oracle.com>  wrote:
>>
>> On 29/12/2017 00:33, Steven Schlansker wrote:
>>> Thanks for the discussion!
>>>
>>> So, it sounds like amending the message by default is going to be a non-starter -- but at least adding the information otherwise might be possible.
>>>
>> There are examples in other area where exceptions include detail information (for diagnostics purposes) when not running with a security manager. This may be something to look at here (and easy to try out too as it wouldn't require touching any native code either).
> I like that!
>
> For now, I will proceed with improving my prototype to follow this suggestion -- unless there is a security manager, the exceptions are annotated.
>
> An alternate way to activate it, by configuring the platform logger e.g. "java.net.SocketException=TRACE", might be useful in case we want to allow end users to configure the feature explicitly and independent of security manager.
>
> Unfortunately I don't see how I can avoid changing the native code -- the exception message is initialized in native code, and by the time we call back to Java code, the necessary information is not passed in to the SocketException subclass constructor.  So I may be misinterpreting your guidance here, but I'm not seeing it.
>
> I think I will hold off on adding Java level fields to the exception types.  I expect if I do that, I will then have to get a spec change to add appropriate public API to make the data actually usable.  Since the goal here is for log diagnostics as opposed to more structured data at the Java level, I'll avoid it.  It also avoids any complications with regards to changing the serial format for such a common type.  But I do think it means the work has to be done in the native code.
>

I haven't studied the actual code, but one thing to consider might be to 
create a java.net package-private exception type (unrelated to 
java.net.SocketException) with a constructor that takes necessary 
information (host, IP, port, but no message) and then throw this 
exception from native code instead of java.net.SocketException. On the 
Java side, you then wrap calls to native methods with try/catch and 
throw java.net.SocketException with appropriately formatted message 
instead (and with no cause). Moving formatting logic to Java might 
simplify native code and it's always good to keep native code simple 
(not having to deal with SecurityManager, system properties, logger(s) 
etc.).

What do you think?

Regards, Peter