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

Сколько раз в Java-журналах я получаю что-то вроде:

Caused by: java.sql.BatchUpdateException: failed batch
    at org.hsqldb.jdbc.jdbcStatement.executeBatch(jdbcStatement.java:1102)
    at org.hsqldb.jdbc.jdbcPreparedStatement.executeBatch(jdbcPreparedStatement.java:514)
    at org.hibernate.jdbc.BatchingBatcher.doExecuteBatch(BatchingBatcher.java:48)
    at org.hibernate.jdbc.AbstractBatcher.executeBatch(AbstractBatcher.java:242)
    ... 113 more

Кто-нибудь знает, как получить полную индикацию stacktrace (т.е. показать остальные 113 строк)?

JavaDocs (для Java 7) для Throwable имеют довольно подробное объяснение того, что происходит.

Ответы

Ответ 1

Когда вы видите "... еще 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, а затем с последующим трассированием вверх - это то же самое, что и исключение оболочки.

Ответ 2

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

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

Ответ 3

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

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 выдает a 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)

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

Ответ 4

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