Code review request: 6973831 NPE when printing stack trace of OOME

[David Holmes]

Mandy Chung said the following on 08/13/10 04:29:
>  On 08/11/10 18:26, David Holmes wrote:
>> I'm a bit behind on this functionality as I have no ideas what a 
>> suppressed exception is. :) 
> 
> FWIW.  The suppressed exceptions are added for automatic resource 
> management (6911258).
>    
> http://mail.openjdk.java.net/pipermail/coin-dev/2009-February/000011.html

Can't say I'm enthralled with the suppressed-exception part of this.

>> That aside I'm curious as to the expected multi-thread usage for an 
>> exception that requires these things to be thread-safe ? Given an 
>> exception occurs in a given thread, passing it to another thread 
>> should require some form of safe-publication.
>>
> 
> Agree.  May I count you as a reviewer?
>    http://cr.openjdk.java.net/~mchung/6973831/webrev.02/

Reviewed. :)

David

> Thanks
> Mandy
> 
>> David
>>
>> Mandy Chung said the following on 08/12/10 07:57:
>>>  On 08/11/10 14:43, Mandy Chung wrote:
>>>>  On 08/11/10 14:03, Rémi Forax wrote:
>>>>> Brian, Mandy,
>>>>> It seems this is not the sole thread-safety issue,
>>>>> access to fields 'cause' or 'stackTrace' aren't thread safe too and 
>>>>> detailMessage is not final.
>>>>>
>>>>
>>>> I agree that the getCause and setStackTrace method need to be 
>>>> synchronized.  On the other hand, the initCause and setStackTrace 
>>>> methods are used to override the values initialized in the 
>>>> constructor and so access to these fields are likely safe in 
>>>> practice.  I can fix it as part of this fix.
>>>>
>>>
>>> Fixed the getCause and setStackTrace methods:
>>>    http://cr.openjdk.java.net/~mchung/6973831/webrev.02/
>>>
>>> Mandy
>>>
>>>> The "detailMessage" is not final because the VM in fact preallocates 
>>>> Throwable object (OOME and ArithmeticException) and then sets the 
>>>> 'detailMessage' field directly (as the constructor is not invoked).
>>>>
>>>> Mandy
>>>
>