Java 如何停止在日志中截断堆栈跟踪
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/437756/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
How do I stop stacktraces truncating in logs
提问by SCdF
Lots of times in Java logs I'll get something like:
很多时候在 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
Does anyone know how to get the full stacktrace showing (i.e. show the other 113 lines)?
有谁知道如何显示完整的堆栈跟踪（即显示其他 113 行）？
The JavaDocs (for Java 7)for Throwable have a pretty detailed explanation of what's going on.
Throwable的JavaDocs（适用于 Java 7）对正在发生的事情有非常详细的解释。
采纳答案by Cowan
When you see '...113 more', that means that the remaining lines of the 'caused by' exception are identical to the remaining lines from that point on of the parent exception.
当您看到“...113 more”时，这意味着“由”异常的其余行与从父异常的那一点开始的其余行相同。
For example, you'll have
例如，你将有
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>.
The two stack traces 'meet' at AbstractBatcher.executeBatch, line 242, and then from then on the upward call trace is the same as the wrapping exception.
两个堆栈跟踪在 AbstractBatcher.executeBatch 第 242 行“相遇”，然后从那时起向上调用跟踪与包装异常相同。
回答by Hes Siemelink
Apache's Commons Langprovides a nice util method ExceptionUtils.printRootCauseStackTrace()which prints a nested stacktrace 'upside down'. The result is much more intuitive.
Apache 的Commons Lang提供了一个很好的实用方法ExceptionUtils.printRootCauseStackTrace()，它打印嵌套的堆栈跟踪“颠倒”。结果更加直观。
If you see the result next to the original out of the printStackTrace() method, it will be clear where the '113 more' lines went.
如果您在 printStackTrace() 方法的原始结果旁边看到结果，那么“另外 113 行”的位置就一目了然了。
回答by MartinGrotzke
In a blog post I just described how to get more than just "BatchUpdateException: failed batch": set hibernate.jdbc.factory_class=org.hibernate.jdbc.NonBatchingBatcherFactoryto disable batching in hibernate.
Normally one can use BatchUpdateException.getNextExceptionto get the reason of the failure, but in some cases this may return null. Then it's useful to disable batching completely.
在一篇博客文章中，我刚刚描述了如何获得不仅仅是“BatchUpdateException: failed batch”：设置hibernate.jdbc.factory_class=org.hibernate.jdbc.NonBatchingBatcherFactory为在休眠状态下禁用批处理。通常可以使用BatchUpdateException.getNextException来获取失败的原因，但在某些情况下，这可能会返回null。然后完全禁用批处理很有用。
回答by Kevin Wheeler
I like the example found 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
Basically in the source code, maincalls function awhich calls function bwhich calls ... which calls function e.
Function ethrows a LowLevelExceptionwhich causes function c to catch the LowLevelExceptionand throw a MidLevelException(wrapping the LowLevelExceptioninstance inside of the MidLevelExceptioninstance. The Exceptionclass has a constructor that is capable of taking in a different exception, wrapping it). This causes function a to catch the MidLevelExceptionand throw a HighLevelExceptionwhich now wraps the previous two Exceptioninstances.
基本上在源代码中，main调用function awhich 调用function bwhich 调用 ... which 调用function e.
Function ethrows aLowLevelException导致函数 c 捕获LowLevelException并抛出 a MidLevelException（将LowLevelException实例包装在实例内部MidLevelException。Exception该类有一个构造函数，能够接受不同的异常，包装它）。这会导致函数 a 捕获MidLevelException并抛出 aHighLevelException现在包装前两个Exception实例。
As noted in the other answers, the stack trace isn't really truncated, you are seeing the full stack trace. The .. .3 morein my example is there because it would be redundant otherwise. If you wanted to be redundant and waste output lines, .. 3 morecould be substituted with
正如其他答案中所述，堆栈跟踪并没有真正被截断，您看到的是完整的堆栈跟踪。将.. .3 more在我的例子是存在的，因为它是多余的，否则。如果你想冗余和浪费输出线，.. 3 more可以用
at Junk.b(Junk.java:17)
at Junk.a(Junk.java:11)
at Junk.main(Junk.java:4)
But there is no need to output these three lines, because they are already implied.
但是没有必要输出这三行，因为它们已经被隐含了。
回答by Nikita Koksharov
Increase -XX:MaxJavaStackTraceDepthJVM option.
增加-XX:MaxJavaStackTraceDepthJVM选项。
回答by DAB
I found this useful to get the whole picture. Get a full stack trace of the Exception andthe cause (which often shows repeated lines from the main Exception, but can be helpful).
我发现这对获得全貌很有用。获取异常和原因的完整堆栈跟踪（通常显示主异常中的重复行，但可能会有所帮助）。
... 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);
}
}
}
