commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henri Yandell <flame...@gmail.com>
Subject Re: [LANG] 2.4: ExceptionUtils.getFullStackTrace()
Date Sun, 08 Nov 2009 18:07:44 GMT
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 <chuckdeal97@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 <pbenedict@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 <flamefew@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 <chuckdeal97@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


Mime
View raw message