RFR: jsr166 jdk9 integration wave 2

Martin Buchholz martinrb at google.com
Thu Dec 10 16:29:55 UTC 2015


On Thu, Dec 10, 2015 at 2:58 AM, Timo Kinnunen <timo.kinnunen at gmail.com> wrote:
> This seems problematic to me, because it breaks the expectation that the
> most important part of the stack trace can be found at the bottom of the it.
> In this case, if someone subsequently wraps the original exception in their
> own Exception the causal chain then gets jumbled. I actually wish
> printStackTrace processed the exceptions in the main trace  in reverse
> compared to how it is now. If, rather than finding this at the end of a
> stack trace:

Timo, this is a new idea to me - I always read stacktraces "from the
top".  But I've never had to debug those large java apps that real
java programmers maintain.

I like having the top exception be the "real" one instead of one we
fabricated to help the user.  I think now I finally understand weird
stacktraces in forkjoin tests that came from
ForkJoinTask.getThrowableException where I was wondering why the
exception appeared to be repeated and why the exception message was
missing.



More information about the core-libs-dev mailing list