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