Hi David,
Exceptions should have a detail message that is useful.
For EIIE, all of the salient information is in the message of the cause and
is much more useful that something generic that just echos the EIIE's type.
Without a stacktrace EIIE, with a generic message is nearly useless.
Generally, where an exception is caught just to be wrapped and
propagated with a
different type, the message from the underlying cause is more useful to
report.
$.02, Roger
On 8/16/18 6:22 PM, David Holmes wrote:
On 17/08/2018 1:18 AM, mandy chung wrote:
On 8/15/18 11:00 PM, David Holmes wrote:
Hi Mandy,
Not a review - sorry :)
On 16/08/2018 7:46 AM, mandy chung wrote:
ExceptionInInitializerError(Throwable cause) sets the detail
message to null. It'd be helpful to include a detail message
rather than null
as in Throwable(Throwable cause) that constructs a new throwable
with a default message cause==null ? null : cause.toString().
This would help troubleshooting of writing new bootstrap methods
where VM currently asserts non-null linkage error message [1] where
there are other solutions such as constructing the message in
the VM or removing the assert.
I think that's just a bug in the VM code making inappropriate
assumptions! There shouldn't have to be a detail message, especially
in a wrapping exception like ExceptionInInitializerError! It only
gets thrown because some other exception was thrown, there's really
no more detail for the EIIE itself. Promoting the cause's detail
message to be the detail message of the EIIE just seems wrong to me.
I think even VM removes the assert, I don't see how EIIE includes
the detail message is wrong? It's consistent with the
Throwable(Throwable cause) constructor.
I think it is wrong because the message is not that of the EIIE but
that of the original exception.
If EIIE must have a detail message then that should just be something
explicit like:
Caused by <cause exception type> : <cause detail message>
Unlike general Throwables that may or may not have a cause, a true
EIIE must always have a cause when thrown by the JVM.
David
-----
Did this come about through the new code that saves the original
cause of the EIIE so that it can be reported when the subsequent
NoClassDefFoundError is thrown due to the class being in the
erroneous state? (I don't recall if that actually got pushed.)
I am not sure but I don't think so. I ran into this when I develop
the bootstrap methods. I think this is a good EIIE clean up.
Mandy
