8212620: Provide a mechansim to allow a class/method to request filtering from the stack trace

Rob Spoor openjdk at icemanx.nl
Thu Jan 10 19:30:03 UTC 2019


I had an idea that can possibly help solve three issues:
* 8212620
Provide a mechansim to allow a class/method to request filtering from 
the stack trace
* 8211152
Improve unclear and incomplete Exception stack trace
* 6507809
"Caused by" notation for stack traces unnecessarily hard to read


The issue described in all three is that the way stack traces are 
printed is different from what people want. One solution could be to 
pull the formatting logic away from Throwable. This can be done by 
introducing an interface similar to Thread.UncaughtExceptionHandler. For 
instance:

     public interface StackTracePrinter {
         void printStackTrace(Throwable t, PrintStream out);
         void printStackTrace(Throwable t, PrintWriter out);
     }

Throwable could get a static defaultStackTracePrinter field like 
Thread.defaultUncaughtExceptionHandler, and Throwable's printStackTrace 
methods would delegate to this default.

There can then be implementation DefaultStackTracePrinter that uses the 
current format, and different implementations for the three issues. 
(Small implementation improvement: instead of using PrintStreamOrWriter, 
WrappedPrintStream and WrappedPrintWriter, the private printStackTrace 
method could take a lock and a Consumer<String> as arguments. This would 
then be called as "printStackTrace(s, s::println)".)


Unfortunately, getOurStackTrace() will not be available to all 
implementations, so to prevent having to call getStackTrace() Throwable 
should get another method List<StackTraceElement> getStackTraceList() 
that returns List.of(getOurStackTrace()) (possibly cached), or otherwise 
Collections.unmodifiableList(Arrays.asList(getOurStackTrace())).


There is one thing that I haven't been able to figure out though, and 
that's specifying different StackTracePrinters for different 
applications in application containers etc. Maybe someone can think of a 
good mechanism to support this.



More information about the core-libs-dev mailing list