RFR JDK-8209553: ExceptionInInitializerError can have a default detail message if the cause is given
Roger Riggs
roger.riggs at oracle.com
Fri Aug 17 13:16:07 UTC 2018
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
More information about the core-libs-dev
mailing list