This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Stack traces
- To: "Nic Ferrier" <nferrier at tapsellferrier dot co dot uk>
- Subject: Stack traces
- From: Andrew Haley <aph at cambridge dot redhat dot com>
- Date: Mon, 2 Jul 2001 22:16:48 +0100 (BST)
- Cc: java at gcc dot gnu dot org
- References: <sb40de4f.076@tapsellferrier.co.uk>
Nic Ferrier writes:
> I've noticed a small but annoying problem with Throwable.
>
> The fillinStackTrace gets the whole stack trace, not the stack trace
> from where the error occurred.
>
> That means that Throwable is always in the stack trace.
>
> That's not right is it? It's certainly annoying when you're trying to
> debug stuff.
fillinStackTrace() doesn't know where it's been called from, so it
starts with the frame above itself. Generally, that's Throwable().
However, if you call fillinStackTrace() directly from a method
foo.bar(), you _do_ want foo.bar() to appear in the stack trace.
We could get around this by having a privateFillinStackTrace() that
Throwable() calls. Is it worth it? According to the ABI doc,
Throwable() calls fillInStackTrace(), so I don't even know if this
would be legal.
Andrew.