Exception stack trace printing starting from root cause
-------------------------------------------------------
Key: LBCLASSIC-217
URL: http://jira.qos.ch/browse/LBCLASSIC-217
Project: logback-classic
Issue Type: New Feature
Affects Versions: 0.9.22
Reporter: Tomasz Nurkiewicz
Assignee: Logback dev list
A typical exception in multi-tier application looks similar to this:
com.acme.BusinessException: Can't process request
at ...
at ...
Caused by: com.acme.dao.PersistenceException: Can't access database
at ...
at ...
... 49 common frames omitted
Caused by:
org.springframework.jdbc.datasource.lookup.DataSourceLookupFailureException:
Unable to locate datasource
at ...
at ...
... 65 common frames omitted
Caused by: java.net.UnknownHostException: Unknown host localhostt
at ...
at ...
... 84 common frames omitted
The deeper exception, the more specific information it gives. Typically the
last "Caused by" is the most interesting one. So it seems like reversing the
order in which the exceptions are thrown (from most specific to consecutive,
less specific wrappers) might be more intuitive:
java.net.UnknownHostException: Unknown host localhostt
at ...
at ...
Wrapped by:
org.springframework.jdbc.datasource.lookup.DataSourceLookupFailureException:
Unable to connect to the database
at ...
at ...
Wrapped by: com.acme.dao.PersistenceException: Can't access database
at ...
at ...
Wrapped by: com.acme.BusinessException: Can't process request
at ...
at ...
It is not only easier to read and follow (business exception is interesting for
the end user while the most precise, technical information is for developers
and system administrators - so it should be easily accessible in the logs), but
also the stack trace isn't mixed. You can read stack frames in exactly the same
order as they were executed, no need to jump from one stack trace line to
another (see attachment from the real application). This also means that the
beginning of the thread is always at the bottom and the line that caused the
very first exception - at the top. (look at the attached real exception)
I already implemented this feature by adding
RootCauseFirstThrowableProxyConverter extending
ch.qos.logback.classic.pattern.ExtendedThrowableProxyConverter. It is turned on
by appending "%rEx" to the encoder pattern. If you like this feature, I will
push the changes (just few classes have changed) into my GitHub fork.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.qos.ch/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
_______________________________________________
logback-dev mailing list
[email protected]
http://qos.ch/mailman/listinfo/logback-dev
