You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@commons.apache.org by Charles Deal <ch...@gmail.com> on 2009/11/04 23:08:36 UTC
[LANG] 2.4: ExceptionUtils.getFullStackTrace()
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.
Re: [LANG] 2.4: ExceptionUtils.getFullStackTrace()
Posted by Henri Yandell <fl...@gmail.com>.
I think if the full stack trace isn't being shown, then it's a bug. I
think the bug is in the first nested exception though - it should be
printing the rest of the stack trace and it sounds like it isn't in
your situation.
Which matches my experience with the ServletException (and I guess
JasperException) in Tomcat. They don't print the rest of their stack
trace, making debugging very hard.
Hen
On Fri, Nov 6, 2009 at 11:26 AM, Charles Deal <ch...@gmail.com> wrote:
> 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
> JasperException).
>
> 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 <pb...@apache.org> 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 <fl...@gmail.com> 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 <ch...@gmail.com>
>> 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: user-unsubscribe@commons.apache.org
>> > For additional commands, e-mail: user-help@commons.apache.org
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
>> For additional commands, e-mail: user-help@commons.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org
Re: [LANG] 2.4: ExceptionUtils.getFullStackTrace()
Posted by Charles Deal <ch...@gmail.com>.
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
JasperException).
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 <pb...@apache.org> 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 <fl...@gmail.com> 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 <ch...@gmail.com>
> 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: user-unsubscribe@commons.apache.org
> > For additional commands, e-mail: user-help@commons.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
> For additional commands, e-mail: user-help@commons.apache.org
>
>
Re: [LANG] 2.4: ExceptionUtils.getFullStackTrace()
Posted by Paul Benedict <pb...@apache.org>.
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 <fl...@gmail.com> 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 <ch...@gmail.com> 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: user-unsubscribe@commons.apache.org
> For additional commands, e-mail: user-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org
Re: [LANG] 2.4: ExceptionUtils.getFullStackTrace()
Posted by Henri Yandell <fl...@gmail.com>.
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 <ch...@gmail.com> 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: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org