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