Hi Steven,
Steven Schlansker je 02. 01. 2018 ob 22:25 napisal:
On Jan 2, 2018, at 8:35 AM, Alan Bateman<alan.bate...@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
