On 10/01/2019 22:59, Mandy Chung wrote:
On 1/10/19 11:30 AM, Rob Spoor wrote:
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
This RFE is not just about stack trace format and a generic stack trace
printer has no knowledge if a stack frame is implementation-specific. A
library developer may want certain classes or methods to hide from the
user (eliminating the implementation details) and remove noise from the
stack trace.
One idea is some kind of annotation that a library developer can tag the
methods to be hidden from stack trace by default.
So this proposal does not address the use case of 8212620.
I may have RFE 8212620 differently. My proposal would also allow stack
trace elements to be filtered out of stack traces, by providing a
filtering StackTracePrinter. This would be initiated from the caller (or
system if the default is replaced). I now see that 8212620 is about
letting the called method or class itself determine that it should show
up in stack traces. Both solutions could give the same end result, and
could probably even be mixed.
* 8211152
Improve unclear and incomplete Exception stack trace
* 6507809
"Caused by" notation for stack traces unnecessarily hard to read
I didn't spend time on this. The only thing I would say about these 2
RFEs is that they both propose to change the current stack trace format
that will likely break tools parsing the output. Keeping the default
format unmodified and allowing to plugin a custom formatter is one
option to consider.
Mandy
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.
