Uploaded image for project: 'logback'
  1. logback
  2. LOGBACK-547

Exception stack trace printing starting from root cause

    XMLWordPrintable

Details

    • Icon: New Feature New Feature
    • Resolution: Fixed
    • Icon: Major Major
    • 0.9.30
    • 0.9.22
    • None
    • None

    Description

      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.

      Attachments

        Activity

          People

            logback-dev Logback dev list
            nurkiewicz Tomasz Nurkiewicz
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: