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

[Rob Spoor]

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.