Only the root cause stack trace is visible in filtered stack traces

[mrmanc]

(forked from #98)

I’ve noticed that only the stack trace of the root cause is printed when the stack trace is filtered. Looking at the code this appears to be intentional. I can see someone might only care about the root cause, but I wondered about whether you feel it would be worth separating the ability to filter uninteresting packages from the full stack trace from the ability to present the filtered root cause?
—@mrmanc

@mrmanc you raised an interesting issue.

I think it could make sense to keep only the trace of the caught exception, the first n exceptions (seen from the caught exception) or the last n exceptions (seen from the root cause exception). This could play nicely with filterStackTrace=1 (keep only 1 exception from the caught side)/filterStackTrace=-1(keep only the first exception from the cause side).

Does this make sense?
—@mp911de

While looking at a possible fix for this I because curious about this, and writing a test case to see if I could fix it easily I realised that there is interesting logic in Throwable.printEnclosedStackTrace() around compressing common frames (see ... 29 more in the details below) which you lose by implementing the printing of the stack trace elements yourself. I speculated that you chose this approach to be able to easily restrict the print to the last Throwable in the chain which makes sense.

``` java.lang.Throwable: This is the wrapper at biz.paluch.logging.StackTraceFilterTest.doesNotFilterDoubleThrowable(StackTraceFilterTest.java:41) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:483) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) at org.junit.runners.ParentRunner.run(ParentRunner.java:309) at org.junit.runner.JUnitCore.run(JUnitCore.java:160) at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:117) at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:42) at com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:262) at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:84) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:483) at com.intellij.rt.execution.application.AppMain.main(AppMain.java:147) Caused by: java.lang.Throwable: This is the cause ... 29 more ```

When printing multiple traces though I think it would be better to simply parser / filter the Throwable output itself to get the benefit of common frame deduplication and adding the package filtering over the top. Making the depth of traces to present would be problematic with this approach as you wouldn’t know whether you were losing frames presented further up the chain which you had chosen to hide. You could solve this by only allowing positive integers and using it to compute the height in the stack to start from (perhaps interpreting 0 as the full height), but this doesn’t seem very useful.

My ‘keep it simple’ instincts suggests allowing the user to choose to invoke Throwable.printStackTrace() on the root cause and filter for packages or to invoke Throwable.printStackTrace() on the first Throwable in the chain and filtering for packages.

[mp911de]

That's fixed now with fa075fb. extractStackTrace allows selection of the desired exception (1 for the cause, -1 for the root cause, 2 for the cause's cause and so on.)

[mrmanc]

Looks interesting, thanks! I’ll get back to you with feedback for this too.