I'm a bit behind on this functionality as I have no ideas what a
suppressed exception is. :) 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.
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
