So, this aspect of COIN is still somewhat new, and so I think it is worth looking at carefully. There is a specification for this feature that was discussed on coin-dev. You might want to take a look and comment -- its not too late.
On Aug 12, 2010, at 5:00 PM, David Holmes wrote: > 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 >>>>
