Java stack traces

jdavidb on 2008-01-31T14:05:52

The call depth of Java exception stack traces never ceases to amaze me. These are easily 200 levels deep. I know I'm seeing things that trace back deep into the bowels of our application server, but I also remember working with much simpler Java programs in school that were still 50 levels deep or so.

I don't think anything I wrote in Perl ever had that many routines calling that many routines. Even if they had a comparable number of routines, they didn't go that deep.

---

proxies are part of the problem

lachoy on 2008-01-31T15:17:02

A lot of systems today use one or more proxies around a number of objects to implement declarative transactions or other goodies. (Of course, these are much easier to implement in Perl or other dynamic languages, but that's another show.) So as a result you'll frequently have a number steps where each proxy intercepts the method, figures out what to dispatch it to, then invoke the relevant method using reflection.

Fun when debugging, too...

Re:proxies are part of the problem

jdavidb on 2008-01-31T18:51:37

Yes; I'm seeing a lot of those.

There needs to be the equivalent of goto &NAME in Java.

in perl

rjbs on 2008-01-31T15:55:25

Yeah, I'm starting to boggle at the Java-length stacks I'm seeing from my code that uses both Moose and POE. Pages and pages long.

Re:in perl

jrockway on 2008-01-31T22:33:13

That's 'cause stevan loves longmess apparently.

As for Java, the call traces are deep because you see the call stack all the way down to "main". Try going 50 levels deep in a mod_perl app, then looking at the C stack in GDB. It's deep because you have Apache in there, then Perl, then Perl's management of your stack.

Re:in perl

Aristotle on 2008-02-01T11:04:18

Be nice if he gave the user the choice. There’s always Carp::Always for those times you do need a full trace, and then you get one from any uncaught exceptions, not just those where the author coöperated. And the rest of the time, you can leave it out.