Как остановить усечение трассировки стека в журналах

Когда вы видите «... еще 113», это означает, что оставшиеся строки исключения «вызвано» идентичны оставшимся строкам родительского исключения с этой точки.

Например, у вас будет

com.something.XyzException
  at ...
  at ...
  at org.hibernate.jdbc.AbstractBatcher.executeBatch(AbstractBatcher.java:242)
  at ... <the other 113 lines are here>...
Caused by: <the above>.

Две трассировки стека «встречаются» в AbstractBatcher.executeBatch, строка 242, и с этого момента восходящая трассировка вызова такая же, как исключение упаковки.

Apache Commons Lang предоставляет хороший служебный метод ExceptionUtils.printRootCauseStackTrace (), который печатает вложенную трассировку стека «вверх ногами». Результат намного более интуитивный.

Если вы увидите результат рядом с исходным результатом метода printStackTrace (), будет ясно, куда делись «еще 113» строк.

В сообщении в блоге я только что описал как получить больше, чем просто «BatchUpdateException: неудавшаяся партия»: установить hibernate.jdbc.factory_class=org.hibernate.jdbc.NonBatchingBatcherFactory для отключения пакетной обработки в спящем режиме. Обычно можно использовать BatchUpdateException.getNextException, чтобы выяснить причину сбоя, но в некоторых случаях это может вернуть null. Тогда полезно полностью отключить пакетирование.

Мне нравится найденный пример здесь:

HighLevelException: MidLevelException: LowLevelException
         at Junk.a(Junk.java:13)
         at Junk.main(Junk.java:4)
 Caused by: MidLevelException: LowLevelException
         at Junk.c(Junk.java:23)
         at Junk.b(Junk.java:17)
         at Junk.a(Junk.java:11)
         ... 1 more
 Caused by: LowLevelException
         at Junk.e(Junk.java:30)
         at Junk.d(Junk.java:27)
         at Junk.c(Junk.java:21)
         ... 3 more

В основном в исходном коде main вызывает function a, который вызывает function b, который вызывает ... который вызывает function e. Function e генерирует LowLevelException, в результате чего функция c перехватывает LowLevelException и генерирует MidLevelException (обертывание экземпляра LowLevelException внутри экземпляра MidLevelException. Класс Exception имеет конструктор, который может принимать другое исключение, обертывая его). Это заставляет функцию a поймать MidLevelException и выбросить HighLevelException, который теперь обертывает предыдущие два экземпляра Exception.

Как отмечалось в других ответах, трассировка стека на самом деле не усекается, вы видите полную трассировку стека. .. .3 more в моем примере присутствует, потому что в противном случае он был бы избыточным. Если вы хотите быть избыточными и лишними выходных линий, .. 3 more можно заменить на

at Junk.b(Junk.java:17)
at Junk.a(Junk.java:11)
at Junk.main(Junk.java:4)

Но эти три строчки выводить не нужно, потому что они уже подразумеваются.

Увеличьте опцию -XX:MaxJavaStackTraceDepth JVM.

Я нашел это полезным, чтобы получить полную картину. Получите полную трассировку стека исключения а также причины (который часто показывает повторяющиеся строки из основного исключения, но может быть полезным).

        ... catch( Exception e) ...

        ... catch( NoClassDefFoundError e)
        {

                for(StackTraceElement ste: e.getStackTrace())
                {
                    System.out.println(ste);
                }

                if ( e.getCause()!=null )
                {
                    for(StackTraceElement ste: e.getCause().getStackTrace())
                    {
                        System.out.println(ste);
                    }
                }
        }