commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Charles Deal <>
Subject Re: [LANG] 2.4: ExceptionUtils.getFullStackTrace()
Date Fri, 06 Nov 2009 19:26:22 GMT
If the code is trying to protect against cycles, maybe it should try a
different approach.

In my specific case, I have a JasperException thrown by Tomcat 5.5.17.  It
contains a NPE as the rootCause.  When I simply printStackTrace() (via slf4j
logger) I only get the JasperException stackTrace.  When I used the
getFullStackTrace() method, I still only got the JasperException trace.

I suppose it is a good idea to prevent cyclic stacktraces and too many
exceptions being rendered, but I think at least ONE of the nested exceptions
should be printed.  Ultimately, though, the developer asked for the
fullstacktrace, so I'm not so sure that the total number of exceptions being
printed is a concern.  Cyclic exceptions, however, would be problematic and
while I agree that this code prevents the cycles, it also prevents it from
displaying any nested exceptions (at least in the cause of the Tomcat

I'm ok using the modified version of the method, but before I wrote JIRA on
the issue, I figured I'd better see if it is truly an issue.  It seems to be
a misleading method name at the very least.

On Thu, Nov 5, 2009 at 12:57 PM, Paul Benedict <> wrote:

> Exception traces can also be cyclic. An exception may set itself as
> the root cause, or A -> B -> A.
> On Thu, Nov 5, 2009 at 11:21 AM, Henri Yandell <> wrote:
> > I think the issue is that if you print the nested exception and keep
> > going, you'll get a lot of duplicates as the nested exception will
> > print all its children, then you'll go ahead and loop into the child.
> >
> > Looking at the source to getThrowableList - it seems to me that the
> > throwable list is top down (ie: exception received and then into its
> > causes and its causes causes etc) so much like your comment on
> > reverse.
> >
> > On Wed, Nov 4, 2009 at 2:08 PM, Charles Deal <>
> wrote:
> >> The getFullStackTrace() method javadoc states "A way to get the entire
> >> nested stack-trace of an throwable....".  However, after gathering the
> >> nested Throwables, it performs a check while processing the array of
> >> Throwables that causes it to abort before it renders the nested
> >> stacktraces.
> >>
> >> My question is: Should the if check be there?  Why go through the
> trouble of
> >> getting the nested Throwables if you are going to short-circuit the
> >> rendering loop?  I suppose it is possible that the intent was to iterate
> the
> >> list in REVERSE and stop the rendering when you hit the Throwable that
> had a
> >> root Cause.
> >>
> >> Any thoughts?  I ended up capturing the getFullStackTrace method and
> removed
> >> the if check within the loop and got exactly what I was looking for.
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> > For additional commands, e-mail:
> >
> >
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message