RFR JDK-8209553: ExceptionInInitializerError can have a default detail message if the cause is given

[David Holmes]

Hi Mandy,

A correction on my part ...

On 17/08/2018 8:22 AM, 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>

This is of course what you actually propose by using cause.toString() - 
for some reason I was thinking you were just using the cause's detail 
message as the EIIE detail message. Sorry about that.

I still don't think this change is actually necessary, but it's fine.

Thanks,
David
-----

> 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