667514 - filename/linenumber in exceptions from eval() and Function() code can be misleading

Status: RESOLVED DUPLICATE of bug 332176

(Core :: JavaScript Engine, enhancement)

Description

[David Flanagan [:djf]]

Attachment: demonstrate the issue

For the purpose of recording filenames and line numbers, Spidermonkey treats the strings passed to eval() and the Function() constructor as if they were simply part of the containing file.  This can make it hard to tell where an exception actually occured.  The attached code for example, throws three exceptions, each of which are reported on line 6.  But in reality, one is thrown from line 3 of the string evaluated on line 4, and one is thrown from line 2 of the string passed to Function() on line 5.

I propose instead that each eval() and Function() be given a fake filename that encode the parent file and the line number at which eval() or Function() was invoked.  For example, an exception thrown from line 2 of a string evaluated at line 10 of foo.js would be reported as "(foo.js:10):2"  I'll attach a patch to do that.

Comment 1

[David Flanagan [:djf]]

Attachment: proposed patch

Are eval() and Function() slow enough paths that I can use JS_snprintf() like this? Can I get away with allocating a char[] on the stack like this?

Comment 2

[Jeff Walden [:Waldo]]

They're reasonably slow paths, yes.  (Although if you can defer the slowness until after the fast-path checking in eval, that's preferable.)

We can usually do better than on-stack raw buffers these days.  I think StringBuffer has an append method that can append from a char* or something.  I don't think we have a way to append a number, stringified, to a StringBuffer.  We should rectify that if we don't -- seems like something we'll want for more than just this (thinking of jsexn.cpp's hoary raw pointer string concatenation here).

Comment 3

[Steve Fink [:sfink] [:s:]]

This is really a dupe of bug 637572, though that one is broader-reaching. We wouldn't want to change this too often, since it's an important part of the API (eg Firebug uses it, and is harmed by its current state.) I don't know if it would be worth doing your proposed change in the interim.