[
http://jira.qos.ch/browse/LBCLASSIC-217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ceki Gulcu resolved LBCLASSIC-217.
----------------------------------
Fix Version/s: 0.9.30
Resolution: Fixed
> 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
> Fix For: 0.9.30
>
> Attachments: wrapped_by_stack_trace.txt
>
>
> 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
