ES6 and Error Object properties
Coincidently, I posted a blog entry on SyntaxError and eval() yesterday:
http://pmuellr.blogspot.com/2009/11/evil-eval.html
On Nov 4, 2009, at 11:10 AM, Kevin Curtis wrote:
This has probably been chewed over but -
The ES5 spec defines 'name' and 'message' as properties of the Error - and ReferenceError, SyntaxError etc - objects.
Currently engines have useful additional non-standard properties: Mozilla - fileName, lineNumber and stack. V8 - stack (and type, arguments). (The string returned by 'stack' is not in the same format as Mozilla). JSC - line, sourceId, sourceURL, expressionBeginOffset, expressionCaretOffset ,expressionEndOffset - and a few others for Statement errors.
Any chance for ES6 on standardizing Error object property/ies which report back the error location.
Maybe a property 'location' on the Error object which returns an
object. e.g e.location -> {fileName:<filename>, pos: <character posNumber>, line:<lineNumber> , lineEnd:<lineNumber>, col:<colNumber> , colEnd:<colNumber>, stack: <stackString>}With maybe pos and line being mandatory properties and the other properties set if they can be set.
Patrick Mueller - muellerware.org
Sure would be nifty to have #file and #line directives, now that
Javascript is the new C.
FWIW, OpenLaszlo generates annotations like so:
Filename, line, column:
/* -- file: lpp-8534.lzx#10.7 -- */
Same file, but line numbering needs to be reset (because output has
more or less lines corresponding to source):
/* -- file: #15 -- */
No corresponding source file (i.e., generated code follows):
/* -- file: -- */
I can see merits to one gigantic comment up front with a mapping table
ala Caja, but we found interspersing them worked better for humans
staring at Javascript "assembly" in a Javascript debugger.
IWBNI @sourceurl could be expanded in some form to work with loaded
files...
Coincidently (!!!), I recently opened a feature request in WebKit on
this topic, kind of:
https://bugs.webkit.org/show_bug.cgi?id=30933
Not sure I'll have time to do anything about it, and surely won't
without some kind of real framework helping out to add support on
their end ...
BTW, I thought JavaScript was the new assembler, not the new C.
On Nov 4, 2009, at 3:04 PM, P T Withington wrote:
Sure would be nifty to have #file and #line directives, now that
Javascript is the new C.FWIW, OpenLaszlo generates annotations like so:
Filename, line, column:
/* -- file: lpp-8534.lzx#10.7 -- */
Same file, but line numbering needs to be reset (because output has
more or less lines corresponding to source):/* -- file: #15 -- */
No corresponding source file (i.e., generated code follows):
/* -- file: -- */
I can see merits to one gigantic comment up front with a mapping
table ala Caja, but we found interspersing them worked better for
humans staring at Javascript "assembly" in a Javascript debugger.IWBNI @sourceurl could be expanded in some form to work with loaded
files...On 2009-11-04, at 14:39, Patrick Mueller wrote:
Coincidently, I posted a blog entry on SyntaxError and eval()
yesterday:pmuellr.blogspot.com/2009/11/evil-eval.html
On Nov 4, 2009, at 11:10 AM, Kevin Curtis wrote:
This has probably been chewed over but -
The ES5 spec defines 'name' and 'message' as properties of the
Error - and ReferenceError, SyntaxError etc - objects.Currently engines have useful additional non-standard properties: Mozilla - fileName, lineNumber and stack. V8 - stack (and type, arguments). (The string returned by 'stack' is not in the same format as Mozilla). JSC - line, sourceId, sourceURL, expressionBeginOffset, expressionCaretOffset ,expressionEndOffset - and a few others for Statement errors.
Any chance for ES6 on standardizing Error object property/ies which report back the error location.
Maybe a property 'location' on the Error object which returns an
object. e.g e.location -> {fileName:<filename>, pos: <character posNumber>,
line:<lineNumber> , lineEnd:<lineNumber>, col:<colNumber> , colEnd:<colNumber>, stack: <stackString>}With maybe pos and line being mandatory properties and the other properties set if they can be set.
Patrick Mueller - muellerware.org
On Nov 4, 2009, at 12:11 PM, Patrick Mueller wrote:
Coincidently (!!!), I recently opened a feature request in WebKit on
this topic, kind of:bugs.webkit.org/show_bug.cgi?id=30933
Not sure I'll have time to do anything about it, and surely won't
without some kind of real framework helping out to add support on
their end ...
SpiderMonkey, when you set the JSOPTION_ATLINE runtime option flag,
understands a comment of this form:
//@line: n
as setting the next line's line number to n. You can coerce the
filename too:
//@line: n, "f"
BTW, I thought JavaScript was the new assembler, not the new C.
What's the difference? :-/.
On Nov 4, 2009, at 12:26 PM, Brendan Eich wrote:
On Nov 4, 2009, at 12:11 PM, Patrick Mueller wrote:
Coincidently (!!!), I recently opened a feature request in WebKit
on this topic, kind of:bugs.webkit.org/show_bug.cgi?id=30933
Not sure I'll have time to do anything about it, and surely won't
without some kind of real framework helping out to add support on
their end ...SpiderMonkey, when you set the JSOPTION_ATLINE runtime option flag,
understands a comment of this form://@line: n
as setting the next line's line number to n. You can coerce the
filename too://@line: n, "f"
My memory failed me -- strike the : and , punctuation from the
examples above:
//@line n
//@line n "f"
I like to punctuate, clearly!
On 2009-11-04, at 15:28, Brendan Eich wrote:
On Nov 4, 2009, at 12:26 PM, Brendan Eich wrote:
SpiderMonkey, when you set the JSOPTION_ATLINE runtime option flag,
understands a comment of this form://@line n
//@line n "f"
Can I enable this option from my script (preferably, or Firebug as a
second choice)?
I'm happy to adopt this syntax as being as good as any other.
On Nov 4, 2009, at 12:39 PM, P T Withington wrote:
On 2009-11-04, at 15:28, Brendan Eich wrote:
On Nov 4, 2009, at 12:26 PM, Brendan Eich wrote:
SpiderMonkey, when you set the JSOPTION_ATLINE runtime option
flag, understands a comment of this form://@line n
//@line n "f"
Can I enable this option from my script (preferably, or Firebug as a
second choice)?
Alas not in content script. It seems the original bug that depended
on //@line infrastructure (which is in SpiderMonkey, ready to be
used), the bug to enable //@line only for our browser UI ("chrome")
and similar such (XBL, XPCOM component) scripts, has stalled:
bugzilla.mozilla.org/show_bug.cgi?id=246286
I will get this bug going again, including the ability to set
_options.atline = true;
in the first <script> in a document, in order to get //@line support
in the rest of the scripts.
Yes, we have runtime option reflection. Try this URL in Firefox's
address bar:
javascript:alert(uneval(_options))
and you should see
({strict:false, werror:false, relimit:false})
The strict option pre-dates ES5 (and ES4/ES3.1) strict mode by many
years, and enables strict warnings. Many of these matched the ES5
strict mode errors (good taste!) so we have reconciled the two
systems, with one exception I know of (we do not give a strict warning
if you use 'with' statements).
The werror option, inspired by GCC's option of the same name, turns
warnings into errors.
The relimit option, if true, limits regexp complexity to O(n^3) in
order to throw exceptions at all-to-easy-to-write exponentially
complex regexps. The limit works by bounding the number of
backtracking steps to the cube of the target string length or 400000,
whichever is larger.
You can assign to these properties, although there's a bug noted here:
bugzilla.mozilla.org/show_bug.cgi?id=452451#c1
which prevents you from seeing relimit set to true -- but it does in
fact get set by assignment if you evaluate
_options.relimit = true;
I'll probably fix this soon.
I'm happy to adopt this syntax as being as good as any other.
It is a candidate, but it is modeled after the C pre-processor, always
a warning sign! I will write a wiki-spec for it and throw it into
strawman:.
Re alt-JS languages and getting line's number from runtime errors -
I'm experimenting with an ECMAScript AST serialization format in JsonML - based on the output from the V8 --print_json_ast shell flag. Line numbers can be passed through as attributes. eg
var ast_str = '["IfStatement", {line:44}, ["CompareOperation", {"op":"GT",}, ..."; JSON.AST.execute(ast_str); -> runtime error line number printed as was explicitly set on the AST node
alt-JS languages/DSL's could target this JsonML format.
On 2009-11-04, at 16:27, Brendan Eich wrote:
Alas not in content script. It seems the original bug that depended
on //@line infrastructure (which is in SpiderMonkey, ready to be
used), the bug to enable //@line only for our browser UI
("chrome") and similar such (XBL, XPCOM component) scripts, has
stalled:bugzilla.mozilla.org/show_bug.cgi?id=246286
I will get this bug going again, including the ability to set
_options.atline = true;
in the first <script> in a document, in order to get //@line support
in the rest of the scripts.
Cool! Thanks.
Re standardizing the Error object properties that provide feedback on the location of the error. (Which can also deal with eval' calls - and eval calling eval). The stack property in V8 looks informative :
var s = "x = 4; eval('x.open()')"; try { z = eval(s); } catch(e) { for (j in e) print("----\n" + j + "\n" + e[j]); print("=====\n" + e); }
Output:-
message Object 4 has no method 'open'
stack TypeError: Object 4 has no method 'open' at eval at eval at zz7.js:3:3 at eval at zz7.js:3:3 at zz7.js:3:7
type undefined_method
arguments open,4
name TypeError
With //@line functionality line numbers in the eval strings could be set - and would thus appear in the Error.stack string.
If a location property were adopted it could be nested when eval was called: print(e.location.location.location.line); 3
This has probably been chewed over but -
The ES5 spec defines 'name' and 'message' as properties of the Error - and ReferenceError, SyntaxError etc - objects.
Currently engines have useful additional non-standard properties: Mozilla - fileName, lineNumber and stack. V8 - stack (and type, arguments). (The string returned by 'stack' is not in the same format as Mozilla). JSC - line, sourceId, sourceURL, expressionBeginOffset, expressionCaretOffset ,expressionEndOffset - and a few others for Statement errors.
Any chance for ES6 on standardizing Error object property/ies which report back the error location.
Maybe a property 'location' on the Error object which returns an object. e.g e.location -> {fileName:<filename>, pos: <character posNumber>, line:<lineNumber> ,
lineEnd:<lineNumber>, col:<colNumber> , colEnd:<colNumber>, stack: <stackString>}
With maybe pos and line being mandatory properties and the other properties set if they can be set.
This has probably been chewed over but - The ES5 spec defines 'name' and 'message' as properties of the Error - and ReferenceError, SyntaxError etc - objects. Currently engines have useful additional non-standard properties: Mozilla - fileName, lineNumber and stack. V8 - stack (and type, arguments). (The string returned by 'stack' is not in the same format as Mozilla). JSC - line, sourceId, sourceURL, expressionBeginOffset, expressionCaretOffset ,expressionEndOffset - and a few others for Statement errors. Any chance for ES6 on standardizing Error object property/ies which report back the error location. Maybe a property 'location' on the Error object which returns an object. e.g e.location -> {fileName:<filename>, pos: <character posNumber>, line:<lineNumber> , lineEnd:<lineNumber>, col:<colNumber> , colEnd:<colNumber>, stack: <stackString>} With maybe pos and line being mandatory properties and the other properties set if they can be set.