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
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/
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
