JavaScript Stack-traces

[William Strathearn]

One of the things that makes browser-side JavaScript development nice
is the ability to get information about the sequence of calls leading
up to a particular caught exception using the information provided in
chain of "arguments.callee.caller" objects in each function call
scope.

With a well crafted utility, this can make for stack-traces that are
almost as useful as they are in most other languages (Java, C++,
Python).

This same utility, if used with scripts running in Rhino will fail to
find a defined arguments.callee.caller or arguments.caller object. Is
there any fundamental reason why Rhino cannot provide the
arguments.callee.caller object, even in un-compiled mode?

[William Strathearn]

I did a bit more searching around and found what is probably an old
but definitive answer to to this problem:
http://osdir.com/ml/java.helma.general/2003-12/msg00009.html

Still, I'd like to contend that stack traces are key to being
productive in a large code base and they would be really great to have
available in at least the base optimization level, even if they go
away in code meant to be run outside of a development environment.

On Dec 17, 11:25 pm, William Strathearn <billythe...@gmail.com>
wrote:

[William Strathearn]

It looks like a __exception__ variable is defined as a local in every
catch block. Printing that will provide the line number of the throw
statement that was caught, which isn't quite as nice as a full trace,
but permits you to drill down into the specific cause of the problem.

On Dec 18, 11:49 pm, William Strathearn <billythe...@gmail.com>

[Norris Boyd]

You're right; we can do better here. Luckily Hannes Wallnoefer
contributed code a while ago for extracting script stack traces and I
had just not been calling it appropriately from the Rhino shell's
error handler. I've just committed a simple change (rhino/toolsrc/org/
mozilla/javascript/tools/ToolErrorReporter.java version 1.16) that
allows Rhino to work as follows:

[rhino] cat test.js
function f(obj) {
return obj.prop;
}

function g() {
f(null);
}

g();
[rhino] java -jar build/rhino1_7R1pre/js.jar test.js
js: uncaught JavaScript runtime exception: TypeError: Cannot read
property "prop" from null

[rhino] java -jar build/rhino1_7R1pre/js.jar -debug test.js
js: "test.js", line 2: uncaught JavaScript runtime exception:
TypeError: Cannot read property "prop" from null
at test.js:2
at test.js:6
at test.js:9

[rhino] java -jar build/rhino1_7R1pre/js.jar -opt -1 test.js
js: "test.js", line 2: uncaught JavaScript runtime exception:
TypeError: Cannot read property "prop" from null
at test.js:2 (f)
at test.js:6 (g)
at test.js:9

Note that with interpreter mode (-opt -1) you get a stack trace with
line numbers and function names. When compiling to class files you get
line numbers and no function names, but only if -debug is enabled.
(For the compiled case we actually generate Java debugging information
in the class file and get the stack trace from the exception.)

This magic all comes from calling
RhinoException.getScriptStackTrace().

--N