Exception causes are truncated while logging exceptions with line number limit

[ZOUG]

When a line number limit is applied to exception logging (e.g. %exception{5}), causes of nested exceptions are also truncated and not shown. In my opinion, exception causes are useful in most cases and should be kept by default.

[BinayakThakur]

Hey @ZOUG , This sounds more like feature and less like bug

[ZOUG]

You are right on this. There is indeed one related issue that is a potential bug though. When I tried %xEx{5}, the depth level is ignored and the stack trace is not truncated at all.

[vy]

@ZOUG, if cause is crucial for your case, can you use %rEx{5} instead? If not, how do you expect Log4j to render your stack trace given you only want to see 5 lines of it?

[ZOUG]

I was considering to move to log4j2 from logback, whose default behavior for %ex{5} is printing 5 lines of stack trace for each exception level (including the outermost exception and its causes). I wasn't aware of the %rEx parameter before. So I tried %rEx{5} and it shows something like this.

java.lang.RuntimeException: Cause
	... 74 more
Wrapped by: java.lang.RuntimeException: Nested exception
	at com.example.LoggingTest.testLogger(LoggingTest.java:20) ~[test-classes/:?]
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103) ~[?:?]

The cause exception is shown -- which is helpful -- but its stack trace is still not printed as expected. Changing 5 to 10 doesn't affect the output of the cause exception.

[vy]

@ZOUG, a Throwable is essentially composed of 3 parts:

1. The stack trace (i.e., StackTraceElement[])
2. A cause (of type Throwable)
3. The suppressed exceptions (of type Throwable[])

Throwable::printStackTrace renders all these and this is what %ex operates on. That is, given %ex{N}, Log4j Core retains the first N lines of the rendered stack trace.

AFAICT, %ex{N} was introduced to avoid excessive stack traces, not to trim redundant information. For your case, I can suggest following options:

1. Combine %ex with %rEx
2. Experiment with discarding certain packages using filters(package,package,...)
3. Implement a custom exception converter matching the behavior of %ex in Logback
4. Submit a feature request

Would you mind sharing a little bit more detail about your deployment setup, please? You write these logs to a... file? If so, then what happens next? Do you feed them to ELK? Can you use JSON Template Layout instead, since it provides an exceptionRootCause resolver?