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

[Mandy Chung]

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.

> * 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.
>