ES6 and Error Object properties
|
View:
New views
11 Messages
—
Rating Filter:
Alert me
|
 |
ES6 and Error Object properties
by kevin curtis
::
Rate this Message:
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. _______________________________________________ es-discuss mailing list es-discuss@... https://mail.mozilla.org/listinfo/es-discuss |
|
|
Re: ES6 and Error Object properties
by Patrick Mueller
::
Rate this Message:
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 - http://muellerware.org/ _______________________________________________ es-discuss mailing list es-discuss@... https://mail.mozilla.org/listinfo/es-discuss |
|
|
Re: ES6 and Error Object properties
by P T Withington
::
Rate this Message:
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: > > 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 - http://muellerware.org/ > > > > > _______________________________________________ > es-discuss mailing list > es-discuss@... > https://mail.mozilla.org/listinfo/es-discuss _______________________________________________ es-discuss mailing list es-discuss@... https://mail.mozilla.org/listinfo/es-discuss |
|
|
Re: ES6 and Error Object properties
by Patrick Mueller
::
Rate this Message:
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: >> >> 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 - http://muellerware.org/ _______________________________________________ es-discuss mailing list es-discuss@... https://mail.mozilla.org/listinfo/es-discuss |
|
|
Re: ES6 and Error Object properties
by Brendan Eich-3
::
Rate this Message:
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: > > 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 ... 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? :-/. /be > > 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: >>> >>> 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 - http://muellerware.org/ > > > > > _______________________________________________ > es-discuss mailing list > es-discuss@... > https://mail.mozilla.org/listinfo/es-discuss _______________________________________________ es-discuss mailing list es-discuss@... https://mail.mozilla.org/listinfo/es-discuss |
|
|
Re: ES6 and Error Object properties
by Brendan Eich-3
::
Rate this Message:
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: >> >> 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 ... > > 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! /be _______________________________________________ es-discuss mailing list es-discuss@... https://mail.mozilla.org/listinfo/es-discuss |
|
|
Re: ES6 and Error Object properties
by P T Withington
::
Rate this Message:
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. _______________________________________________ es-discuss mailing list es-discuss@... https://mail.mozilla.org/listinfo/es-discuss |
|
|
Re: ES6 and Error Object properties
by Brendan Eich-3
::
Rate this Message:
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: https://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: https://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:. /be _______________________________________________ es-discuss mailing list es-discuss@... https://mail.mozilla.org/listinfo/es-discuss |
|
|
Re: ES6 and Error Object properties
by kevin curtis
::
Rate this Message:
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 Wed, Nov 4, 2009 at 8:11 PM, Patrick Mueller <pmuellr@...> wrote: > 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: >>> >>> 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 - http://muellerware.org/ > > > > > es-discuss mailing list es-discuss@... https://mail.mozilla.org/listinfo/es-discuss |
|
|
Re: ES6 and Error Object properties
by P T Withington
::
Rate this Message:
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: > > https://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. _______________________________________________ es-discuss mailing list es-discuss@... https://mail.mozilla.org/listinfo/es-discuss |
|
|
Re: ES6 and Error Object properties
by kevin curtis
::
Rate this Message:
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 _______________________________________________ es-discuss mailing list es-discuss@... https://mail.mozilla.org/listinfo/es-discuss |
| Free embeddable forum powered by Nabble | Forum Help |
