Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ShortenedThrowableConverter: add option to HIDE elements from generated classes #865

Open
brenuart opened this issue Sep 26, 2022 · 2 comments

Comments

@brenuart
Copy link
Collaborator

It may come in handy to provide an option to automatically hide stack trace elements originating from generated classes.

For instance:

org.sample.SampleException: Unable to process request
	at org.sample.MyController.create(MyControllerController.java:41)
	at org.sample.MyController$$FastClassBySpringCGLIB$$340ae8ef.invoke(<generated>)
...

In this example, MyController$$FastClassBySpringCGLIB$$.. is a CGLIB class generated by Spring at runtime. It gives no additional value to report it in the stacktrace and users may want to remove/hide it to increase visibility.

The converter already allows to exclude elements matching a regex pattern. However a stack element is removed only if it is followed (or preceded) by at least one another excluded item. Also, the excluded items are replaced by a single line reporting the number of exclusions ("... 12 frames excluded").

Here we simply want to silently HIDE elements originating from generated classes so the exclusion is not applicable. This feature could leverage the existing StackElementFilter.withSourceInfo() filter and would be enabled using a simple flag as follows:

<filterGeneratedClasses>true</filterGeneratedClasses>

Note: how do we detect generated classes?
Is it enough to say that a class is generated if the filename and the line number are unknown? What if the code is compiled without debugging information?

@brenuart
Copy link
Collaborator Author

@philsttr What's your opinion ?

@philsttr
Copy link
Collaborator

philsttr commented Sep 27, 2022

I'd rather stick to the regexes. There are going to be tons of edge cases for generated classes that I do not think logstash-logback-encode should try to detect. We'll never get it right, and it sounds like a pain to maintain at a library level.

We could add another option to the ShortenedThrowableConverter to define how excluded lines are indicated. Possibly with three values:

  • count = existing behavior (... 2 frames excluded)
  • mark = new behavior to add an indicator character before at
  • none = no indication at all

something like this:

Original (non-shortened):

java.lang.RuntimeException: boom
    at com.foo.A.a()
    at cglib.foo()
    at cglib.bar()
    at com.foo.A.b()
    at java.lang.Thread.run()

count = existing behavior

java.lang.RuntimeException: boom
    at com.foo.A.a()
    ... 2 frames excluded
    at com.foo.A.b()
    at java.lang.Thread.run()

mark = new behavior to add an indicator character before at

java.lang.RuntimeException: boom
    at com.foo.A.a()
   *at com.foo.A.b()
    at java.lang.Thread.run()

none = no indication at all

java.lang.RuntimeException: boom
    at com.foo.A.a()
    at com.foo.A.b()
    at java.lang.Thread.run()

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants