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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >> 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: [email protected] >> > For additional commands, e-mail: [email protected] >> > >> > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
