RFR: jsr166 jdk9 integration wave 2

[Doug Lea]

On 12/03/2015 04:22 AM, Peter Levart wrote:

> What about the 4th option (keep current behavior, but try the best-effort
> with reflection to make new exception of the same type):

We could do this, and if the attempt to clone fails, fall back
to addSuppressed of the original exception. As in:

             } catch (Throwable ex) {
                 if (x == null)
                     x = ex;
                 else if (x != ex) {
                     Throwable cx = tryCloneException(x);
                     if (cx != null)
                         x = cx;
                     x.addSuppressed(ex);
                 }
             }

Although considering the prospects for failure to clone (as also
discussed by Jason),  I'm still not sure it is worthwhile.
Whenever code throws exceptions within exception handlers,
the best you can do inside libraries is to be as informative
as possible to developers, which was among the motivations
for introducing addSuppressed.

Given the choice of visibly (but safely) adding a suppressed
exception while some other stage may be processing the
primary exception (as in the current webrev), vs fallible
reflection-based clone attempts with unknown side effects,
I still think the former is likely to be best-behaved, but
would not object to the mixed approach if we could come up
with a reasonable implementation of tryCloneException.

Also, could you explain...

>
> Note that such code and similar code in ForkJoinTask.getThrowableException
> will probably have to be modified for jigsaw to include dynamic addition of
> read-edge to the module of exception class...
>

-Doug