On Wed, Dec 9, 2009 at 2:56 PM, Hannes Wallnoefer <[email protected]> wrote: > It's really rather a low-tech approach. > RhinoException.getScriptStackTrace() loops through the exception's > stack trace and tries to pick only those elements that represent a > script source. It returns a String with the rendered stack trace, not > an array of stack trace elements, so its only purpose is to be shown > to a human being. > > The hardest part is merging compiled and interpreted code, which can > be on the stack at the same time. For compiled code, it's easy - we > just check the StackTraceElement's fileName against a file name > pattern, which is *.js by default but you can define your own > java.io.FilenameFilter if you want. > > For interpreted code it's a bit harder. The interpreter keeps its own > call frame stack and when a RhinoException is initialized the > interpreter fills in its current stack. Now when walking the java > stack in getScriptStackTrace(), we simply look for frames that > represent the interpreter loop (method "interpretLoop" in class > "org.mozilla.javascript.Interpreter"). If there is a matching > interpreter stack frame as there should be, we fill in its file name > and line number.
Ok...sounds about like what we do in JRuby, though we generally still also maintain a stack for compiled code too (since we're mixed-mode jitting code at runtime). We seek to eliminate that artificial framing, but it's harder to maintain a nice backtrace without it. - Charlie -- You received this message because you are subscribed to the Google Groups "JVM Languages" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=en.
