You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 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.
layoutsAffects one or more Layout pluginsquestionTickets that are not bug reports, but questions
1 participant
Heading
Bold
Italic
Quote
Code
Link
Numbered list
Unordered list
Task list
Attach files
Mention
Reference
Menu
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
-
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 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.
Beta Was this translation helpful? Give feedback.
All reactions