RFR JDK-8209553: ExceptionInInitializerError can have a default detail message if the cause is given
David Holmes
david.holmes at oracle.com
Thu Aug 16 22:22:06 UTC 2018
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
More information about the core-libs-dev
mailing list