[Kaffe] problem with stack traces

Alex Nicolaou anicolao at mud.cgl.uwaterloo.ca
Thu Feb 4 13:28:40 PST 1999

Tony Kimball wrote:
> Quoth Godmar Back on Wed, 3 February:
> :
> : Mo, I implemented a quick version and checked it in:
> : It's not as pretty as Sun's which prints the basename of a SourceFile only,
> : but maybe we don't want that anyway cause it could be ambiguous.
> :
> One is always reluctant to make a statement which might be interpreted
> as a request for someone else to write code, but that fear
> notwithstanding, I will mention, just FYI, that it is a marginally
> common practice to find one's callers by parsing the output of
>     (new Exception("traceback")).printStackTrace()
> I say "marginally common" because I have personal knowledge of at
> least three persons who have independently implemented such code!
> It would much simplify such code, if Kaffe could format tracebacks
> more nearly compatibly -- i.e. use the same separator characters, and
> significant elements per line, whitespace not being important.  (In
> the best of all possible worlds, Kaffe would set an example so good
> that Sun elects to standardize it, and implement a call-stack query
> extension to the reflection interface:-)  But I won't hold my breath.)

I think you've hinted at the right way to "solve" this problem in the
absense of a response from Sun but not come right out and said it. If
someone defines a standard interface for a stack trace, then we can
implement parsers for Sun's JDK or other JDKs that can present that
interface. Meanwhile, Kaffe can implement the interface properly by
providing an implementation of it that uses hooks unique to Kaffe -
behind the scenes, of course.

You'd have code like:

StackTrace trace = StackTraceFactory.create(new Exception("traceback"));
// operations on trace follow that analyze the stack trace

The factory would be replaced according to which VM you were using and
the StackTrace interface would provide the common entry points. Porting
your code to a VM which didn't produce output that one of the
implementations could already parse would involve writing a new stack
trace parser. Of course, I emphasize again that internal to Kaffe there
should be no parsing involved.

The stack trace interfaces used in JVMDI would be the best model, I


PS And yes, in a previous job I did have one of my programmers implement
a stack trace parser for me ... this is a desirable piece of information
that's just too hard to get at.

More information about the kaffe mailing list