如何停止在日志中截断堆栈跟踪答案

【问题标题】：How do I stop stacktraces truncating in logs如何停止在日志中截断堆栈跟踪
【发布时间】：2009-01-13 02:12:53
【问题描述】：

在 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

有谁知道如何显示完整的堆栈跟踪（即显示其他 113 行）？

Throwable 的 JavaDocs (for Java 7) 对正在发生的事情进行了非常详细的解释。

【问题讨论】：

如果您检查之前记录的行，其他 113 行已经在堆栈跟踪中

标签： java exception stack-trace

【解决方案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 行“相遇”，然后从那时起向上调用跟踪与包装异常相同。

【讨论】：

什么？原因和包装异常一样吗？我没明白... couse 应该显示问题所在的行，截断堆栈跟踪时未显示的内容。我有这个问题，想了解这个答案，如果有人可以重新制定它......谢谢！顺便说一句，这个答案似乎没有显示如何打印完整的堆栈跟踪。
@TomBrito 你看到了完整的堆栈跟踪——你有两个例外，一个在另一个里面。如果内部（包装）异常的堆栈跟踪是 A B C D E F G，而外部异常的堆栈跟踪是 A B C Z，那么您将看到带有堆栈跟踪 Z C B A 的 OuterException，由堆栈跟踪“G F E D C ...”的“InnerException”引起然后还有 2 个”。另外 2 个是 A 和 B，来自外部堆栈跟踪，为了简洁起见，它们被省略了。
这个答案不正确。我绝对遇到过其余行不相同的情况。在这种情况下，解决方案是增加堆栈跟踪的最大深度，正如 Nikita Koksharov 在下面指出的那样，通过使用 -XX:MaxJavaStackTraceDepth VM 选项。

【解决方案2】：

Apache 的Commons Lang 提供了一个很好的实用方法ExceptionUtils.printRootCauseStackTrace()，它可以“颠倒”打印嵌套的堆栈跟踪。结果更加直观。

如果您在 printStackTrace() 方法的原始结果旁边看到结果，就会清楚“113 more”行的去向。

【讨论】：

【解决方案3】：

增加-XX:MaxJavaStackTraceDepth JVM 选项。

【讨论】：

为什么这被否决了？这正是答案。设置为 -1 表示无限深度。

【解决方案4】：

我喜欢here找到的例子：

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)

但是这三行不需要输出，因为已经隐含了。

【讨论】：

【解决方案5】：

我发现这对于了解整体情况很有用。获取异常和原因的完整堆栈跟踪（通常显示主异常中的重复行，但可能会有所帮助）。

        ... 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);
                    }
                }
        }

【讨论】：

【解决方案6】：

在一篇博文中，我刚刚描述了how to get more than just "BatchUpdateException: failed batch"：设置hibernate.jdbc.factory_class=org.hibernate.jdbc.NonBatchingBatcherFactory 以禁用休眠中的批处理。通常可以使用BatchUpdateException.getNextException 来获取失败的原因，但在某些情况下可能会返回null。然后完全禁用批处理很有用。

【讨论】：

这没有回答问题。它可能会解决他在现实生活中的情况，因此将其作为评论添加到他的问题中可能比发布答案更有帮助