With all the nascent alt-JS things people are playing with, talked about on this InfoQ blog post, I got to thinking a while back how we could make debugging a little better for these folks in WebKit's Web Inspector.
Java supports meta-data in it's .class files for this sort of information, and I've seen it used for things like debugging Groovy in Eclipse using the stock Java debugger. Not a perfect story, but useful.
So I opened up Bug 30933 - Web Inspector: support for debugging alt-JS files which generate JS. Feel free to drop ideas there.
While chatting with someone who could make use of this, they noted that
their biggest problem was that
eval() doesn't do a very good
job of providing information about syntax errors in the
code. Really? Time for some experiments.
First, why care about
eval() in the first place? Since
it's evil. If code is
code you can just use in the browser with a
element? Sure, you can do it that way. But
why do an off-line compile if you could do the compile in the browser?
Dojo may end up (depending on
your configuration), downloading your source via XHR and then running it
eval() instead of using
Getting good diagnostic information from
eval() would be good for lots of
On to the experiment:
Here's the source of an HTML file to try out with different browsers. There's a link in
the HTML which, when clicked, will run the
function. That function builds a string which will be passed into
I added 100 or so newline's in the source before a string that all the
browsers would actually choke on (took me a minute; my first guesses at
things that would cause syntax errors didn't). The 100 empty lines are to see
with syntax errors are reported, we want to see a line number like 100, not
13 (the line in the source that invokes
The page is also available on my web site.
Below the source are the results you see in the browser after clicking;
these are the properties of the exception object generated by
one per line.
HTML source for test:
WebKit nightly r50423 on Mac (basically, Safari):
Exception: message: Parse error line: 100 sourceId: 4837249224 name: SyntaxError
Opera 10.00 Build 6652 on Mac:
Exception: message: Statement on line 6: Syntax error stacktrace: n/a; see opera:config#UserPrefs|Exceptions Have Stacktrace opera#sourceloc: 6 stacktrace: false
Google Chrome 22.214.171.124 on Mac:
Exception: message: Unexpected token ] stack: SyntaxError: Unexpected token ] at clickMe (http://muellerware.org/exception-in-eval.html:12:8) at unknown source type: unexpected_token arguments: ] name: SyntaxError
Firefox 3.5.4 on Mac:
IE 8.0.7100.0 on Windows 7 RC:
Exception: name: SyntaxError message: Expected '(' number: -2146827283 description: Expected '('
Google Chrome 126.96.36.199 on Windows 7 RC:
Exception: message: Unexpected token ] stack: SyntaxError: Unexpected token ] at clickMe (http://muellerware.org/exception-in-eval.html:13:8) at unknown source type: unexpected_token arguments: ] name: SyntaxError
Yikes, not a pretty picture! WebKit was the only one that got the line number I wanted. But it gave a pretty crappy "message". Nice seeing the "stack" entries for some of the implementations.
There's a question of semantics, of course. The exception generated
from WebKit, with the line number of the
would be confusing had I not caught the exception (though perhaps I'd see
something different in the debugger had I not caught the exception).
In reality, what you may really want
to see, structurally, is something like Java's nestable
eval(), because there are multiple levels of things going
on here; for the ultimate evil,
eval() may end up doing some of it's
In any case, it would be nice to see some of this stuff standardized. In ECMAScript 6, I guess.