For example, in the simple case, suppose I’m using CompletableFuture and the 
value times out with a TimeoutException. This stack trace will include tons of 
entries for java.util.concurrent.CompletableFuture related to the 
transformation pipeline leading up to that point (i.e., transforming 
CompletableFuture instances creates a complicated call stack as an 
implementation detail).

Suppose we then combine some combination of other typical libraries like 
resilience4j, failsafe, spring-retry, micrometer, open telemetry, and then 
integrate with some asynchronous things like netty, reactor, Kotlin coroutines, 
various thread pools and queues, and potentially even some sort of context 
propagation wrappers. In the end, I get a stack trace that’s about 200% longer 
than necessary. IDEs seem to have a feature that can collapse these sorts of 
common parts of the stack trace for comparison.

While I have found that the throwable converter pattern [1] supports filtering 
by a list of package names, this may be overly broad for my use case here 
depending on the structure of the library I’m trying to filter out.

[1]: 
https://logging.apache.org/log4j/2.x/manual/pattern-layout.html#converter-exception

Reply via email to