[Kaffe] new stack trace patch.

[Alex Nicolaou]

Patrick Tullmann wrote:
> 
> > Personally, I consider any code that relies on parsing stack traces
> > highly bogus.
> 
> I second that.  Since stack trace parsing is obviously somewhat
> VM-dependent it shouldn't be too hard to add a
> kaffe.util.StackTraceConverter or something for getting the
> information you're really interested in.  That or just revisit the
> "need" for stack trace parsing...

Since two people have now commented on how using the stack trace is
bogus, I figure I could at least say what we were using it for. In
Eiffel, there's a great assertion construct called "old", which you can
use to compare the value of a variable to its value when the function
was entered. To give a trivial example, the pop() routine of a stack
class would have the following postcondition: size == old size - 1,
since pop removes one item from the stack.

We wanted to implement this for Java. Of course these assertions get
stripped out at production compile time, and of course the code didn't
rely on stack traces for any of its normal function. The stack trace
plus the current thread plus the variable whose old value was being
stored made a sensible unique key for finding the variable again at the
end of the function. So, in Java, the pop() example would look something
like

... pop() {
    Debug.StoreInt( "size", size );
    // do the pop
    Debug.Postcondition(size - 1 == Debug.getInt( "size" ));
}

Off-hand, I can't think of a thread-safe way of implementing this that
doesn't use stack traces and doesn't introduce extra local variables.
Since we didn't want to use a C pre-processor on our Java code,
introducing extra locals didn't seem like a good option. (We did have to
resort to a Java preprocessor to remove all code inside a Debug.*()
method call.)

In general, knowing the stack trace programmatically is a great way to
do certain debugging tasks, and the fact that there's no stack trace
object that can be used to inspect it from running code is clearly an
oversight in the design of the exception objects, which are too deeply
embedded in the VM and don't provide a sufficient interface to Java code
for their functionality.

alex