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

[Peter Levart]

Hi Mandy,

Just a question. Why does "private Throwable exception" field in 
ExceptionInInitializerError exist? Was it there before there was a 
"cause" in Throwable and later still remained there because of 
serialization format? Would it be possible to "simulate" its effect for 
serialization using "serialPersistentFields" and 
ObjectOutputStream.PutField?

The main challegne, I think, would be the deserialization of an old 
ExceptionInInitializerError.exception into new Throwable.cause in case 
the stream did not have Throwable.cause (which is the case for old 
ExceptionInInitializerError(s))

Ragards, Peter

On 08/15/2018 11:46 PM, 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.
>
> This patch proposes to change ExceptionInInitializerError(Throwable 
> cause)
> to default the detail message to cause.toString() if cause is not null.
> It's an incompatibility change; for example existing code that expects
> a null message will now see a detail message.  But the compatibility
> risk should be low as EIIE should be fatal.
>
> This also proposes to add new LinkageError(Throwable cause) constructor
> to retrofit the exception chaining mechanism and that allows to clean up
> the current ExceptionInInitializerError implementation.
>
> Webrev:
> http://cr.openjdk.java.net/~mchung/jdk12/webrevs/8209553/webrev.00
>
> I will create a CSR.
>
> Mandy
> [1] https://bugs.openjdk.java.net/browse/JDK-8208172