I think if the full stack trace isn't being shown, then it's a bug. I
JasperException) in Tomcat. They don't print the rest of their stack
> 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 <
[hidden email]> 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 <
[hidden email]> 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 <
[hidden email]>
>> 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:
[hidden email]
>> > For additional commands, e-mail:
[hidden email]
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
[hidden email]
>> For additional commands, e-mail:
[hidden email]
>>
>>
>
