debugging interfaces

Jordan Osete jor at joozt.net
Mon Jun 15 05:06:02 PDT 2009


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.

-----------------------------------------------

* 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)

Also, exception objects that are thrown by the browser could by default
have a stackTrace property. Please note that if the stack trace is
obtained with getStackTrace, the closest stack frame object would always
be the call to the getStackTrace() function. Thus it could easily be
discarded if needed ( if( stackTrace[ 0 ].func == window.getStackTrace )
stackTrace.shift(); ).

* Why do you think browsers would implement this feature? *

Many browsers already provide a facility for debugging, each giving
different informations. See for example:
https://developer.mozilla.org/En/Core_JavaScript_1.5_Reference/Global_Objects/Error/Stack 

It wouldn't be too hard to standardize that.
The only potential problem I can see is keeping the references to the
variables, arguments, and this object. It would be nice to have
implementors' feedback on this.

* Why do you think authors would use this feature? *

See for example this page, it's an attempt to provide a stack trace in
every browser: http://eriwen.com/javascript/js-stack-trace/

* What evidence is there that this feature is desparately needed? *

It would help every JS programmer out there in JS debugging, and also
libraries for unit testing, etc.

Regards,

Jordan OSETE




More information about the es-discuss mailing list