Reputation: 59378
Lots of times in Java logs I'll get something like:
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)?
The JavaDocs (for Java 7) for Throwable have a pretty detailed explanation of what's going on.
Upvotes: 95
Views: 46366
Reputation: 1
Try the -XX:-OmitStackTraceInFastThrow
JVM option which will stop repeat exceptions from being truncated.
See the following article for additional info: https://yoshihisaonoue.wordpress.com/2021/02/07/jvm-option-xx-omitstacktraceinfastthrow/
Note you should balance performance implications based on the application requirements and real need for this.
Upvotes: 0
Reputation: 1873
I found this useful to get the whole picture. Get a full stack trace of the Exception and the 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);
}
}
}
Upvotes: 0
Reputation: 1452
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, main
calls function a
which calls function b
which calls ... which calls function e
.
Function e
throws a LowLevelException
which causes function c to catch the LowLevelException
and throw a MidLevelException
(wrapping the LowLevelException
instance inside of the MidLevelException
instance. The Exception
class has a constructor that is capable of taking in a different exception, wrapping it). This causes function a to catch the MidLevelException
and throw a HighLevelException
which now wraps the previous two Exception
instances.
As noted in the other answers, the stack trace isn't really truncated, you are seeing the full stack trace. The .. .3 more
in my example is there because it would be redundant otherwise. If you wanted to be redundant and waste output lines, .. 3 more
could be substituted with
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.
Upvotes: 14
Reputation: 459
Apache's Commons Lang provides a nice util method ExceptionUtils.printRootCauseStackTrace() which prints a nested stacktrace 'upside down'. The result is much more intuitive.
If you see the result next to the original out of the printStackTrace() method, it will be clear where the '113 more' lines went.
Upvotes: 22
Reputation: 1301
In a blog post I just described how to get more than just "BatchUpdateException: failed batch": set hibernate.jdbc.factory_class=org.hibernate.jdbc.NonBatchingBatcherFactory
to disable batching in hibernate.
Normally one can use BatchUpdateException.getNextException
to get the reason of the failure, but in some cases this may return null
. Then it's useful to disable batching completely.
Upvotes: -2
Reputation: 37543
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.
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.
Upvotes: 81