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
