« Return to Thread: debugging interfaces
Hi everybody.
I've wondered for some time if it weren't possible to harmonize stack traces across browsers.
I have submitted a (simple) proposal on the WHATWG mailing list (http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-June/020359.html), and got somehow "redirected" here ;-)
So here is the proposal, as I first submitted it. Please tell me if it is not exactly the best place for this.
Part of the functionality proposed here also assumes a browser environment (html / js files) which probably cannot be implemented in some other environments (like JS interpreters).
Also I do not care that much about the proposed property names. They are just here as examples.
Note: unfortunately, I do not "speak" Java at all, and thus I don't know JVM TI. I only skimmed through "JavaTM Virtual Machine Tool Interface (JVM TI)" (http://java.sun.com/javase/6/docs/technotes/guides/jvmti/), but it seems it goes far beyond what I describe here.
Rather than describing the evil things that implementations do with F.caller, we agreed to just impose a blanket prohibition of code peeking into the environment records or identity of strict functions on the stack. This way a test suite can ensure that F.caller does nnot reveal strict functions without us having to introduce the evil things into the standard. I'll write up proposed wording.
-----------------------------------------------
* What is the problem you are trying to solve? *
If you want a traceback, you need to cater for multiple browsers behaviours, and different and incomplete information.
* What is the feature you are suggesting to help solve it? *
Harmonize JavaScript stack traces across browsers. There could be a global getStackTrace() method, wich would return an array of stack frames, closest one first (or last, I don't care). Every stack frame object could have the following properties:
To identify what script we are in:
- the script filename, if external script (JSFileName)
- or HTML filename, in case of an inline script (HTMLFileName)
- or, in case of an "eval()" call, a special evalScope property must be
set to true
- a reference to the script tag DOM object, if the script was not eval'd
(scriptTag)
To identify where in the script we are:
- a simple way to get the script's full source code, whatever way it is
eval'd or included. For example, a fullJSSourceCode property
- the line number, relative to the start of the script (sourceLine)
- the line number, relative to the start of the file containing the
script. It is equal to sourceLine, except if it is an inline script in
an HTML file (fileLine)
- the position of the substring delimiting the instruction in the source
code, relative to the start of the line. This is especially useful if
the JS source is "packed" or minifed, and thus newlines have been
suppressed (instructionOffsetStart and instructionOffsetEnd)
And about the environment:
- a reference to the "this" object in the given stack frame (thisObj)
- a reference to the function called (func). This is a function object.
- the arguments the function was called with, just like the arguments
pseudo-array in a function (arguments)
- a reference to the variable object, that carries all of the variables
that have been defined with the "var" statement, and that can be
accessed in this stack frame ? (variables)
« Return to Thread: debugging interfaces
| Free embeddable forum powered by Nabble | Forum Help |