On Wed, Dec 9, 2009 at 8:26 PM, Charles Oliver Nutter <[email protected]>wrote:
> On Wed, Dec 9, 2009 at 12:06 PM, Hannes Wallnoefer <[email protected]> > wrote: > >> Rhino, in interpreted mode, will inject script stack elements into the > Java stack elements, so above every > org.mozilla.javascript.Interpreter.interpret() element, you'll have all the > JS frames the interpreter created, with an appropriate syntax (function name > + source code name + line number; obviously the class name doesn't > apply...). > > > > Not to forget the getScriptStackTrace() method in RhinoException. This > > works in both compiled and interpreted mode, and returns a (synthetic) > > stack trace including only the script sources. In Helma NG the > > developer is usually presented two dedicated stack traces as shown > > below. I think this is much preferable to messing with the actual > > stack trace which diminishes its usefulness for the language > > implementor. > > > > ReferenceError: "foo" is not defined. > > Script Stack > > at actions.js:67 > > at helma/webapp.js:97 > > at helma/webapp.js:47 > > at helma/middleware/notfound.js:10 > > at helma/middleware/error.js:13 > > at helma/middleware/responselog.js:26 > > at helma/middleware/etag.js:15 > > at helma/middleware/gzip.js:15 > > at helma/jsgi.js:31 > > Can one of you describe how this is done internally in Rhino? We > obviously have the same challenge in JRuby (and probably in Jython > too) but you may have a simpler or more efficient way to do it. > > If you have a point where you can intercept the exception (such as a catch-block where you rethrow the exception, or if it's an exception type you control, you can do it when it is constructed) you can use the getStackTrace and setStackTrace methods to extract the stack-trace and create a new one that better reflects your language. I'm guessing Rhino does something like that, but I would love to get enlightened on either a better way of doing it or the details on how it's done. We currently don't do this in Jython, but we might experiment with doing it in the future. In Jython today we do the same thing you do in JRuby - we keep our own stack of heap-allocated frame objects and construct our own python-traceback from that. Here is a link to code from another project I'm involved with that does filtering of stack traces to not expose the generated glue-methods and internals of the runtime: http://dscm.ops4j.org/git/gitweb.cgi?p=qi4j-core.git;a=blob;f=runtime/src/main/java/org/qi4j/runtime/composite/FragmentInvocationHandler.java;h=81575f6c2601f935228a21d963b54f02b1a33253;hb=HEAD /Tobias -- 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.
