Re: Formalize error.stack?
John Lenz wrote: Column numbers are essential. Yes! Can't forget those. Anything else source-map related? /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: Formalize error.stack?
Column numbers are essential. On Nov 12, 2013 12:28 PM, Domenic Denicola dome...@domenicdenicola.com wrote: I think V8's is preferred. IE10 adopted it, and there's a lot of stack-parsing going on in Node.js land. If SpiderMonkey and JSC would come around to that, it would be lovely. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Formalize error.stack?
It probably makes sense to converge on a common string format. However, I agree with some of the previous replies: if the main motivation for standardising stack traces is to make them processable, then we should focus on introducing a structured format. /Andreas On 12 November 2013 21:33, Oliver Hunt oli...@apple.com wrote: Righto, filed https://bugs.webkit.org/show_bug.cgi?id=124220 —Oliver On Nov 12, 2013, at 12:30 PM, Mark Miller erig...@gmail.com wrote: FWIW, the code I linked to, which arv refers to, when it finds itself on SM, normalizes the SM error stack string to approx v8's format. But the more important part of the answer is the parsed form provided by getCWStack. On Tue, Nov 12, 2013 at 12:20 PM, Oliver Hunt oli...@apple.com wrote: Righto, do we know whether Carakan/V8’s text or SM’s text is preferred? Currently it seems like JSC’s is a little bit weird compare to others, and as i’ve said earlier i’m happy to change it to match another engine (we all have the same info in varying ways, so we can all technically produce the same view in our .stack string) —Oliver On Nov 12, 2013, at 11:17 AM, Erik Arvidsson erik.arvids...@gmail.com wrote: On Tue, Nov 12, 2013 at 12:35 PM, Oliver Hunt oli...@apple.com wrote: The only formatting requirement for the stack property is that if it is present, it must be a string. No. There is a lot of code out there that parses this string and depend on the format. See Mark's reply for one such case. —Oliver On Nov 12, 2013, at 9:23 AM, Erik Arvidsson erik.arvids...@gmail.com wrote: When I started investigating this I had the hope that stack could be standardized. However, the format of the string is cannot be changed without breaking the web so the way forward is to introduce a new property name. But since we are introducing a new property name we should return structured data instead of a plain old string. I haven't had the time to work on this since my initial analysis of the state of the stack property. On Mon, Nov 11, 2013 at 7:51 PM, John Barton johnjbar...@google.com wrote: Note that in Chrome the devtools are remote and error.stack is a getter which issues a remote method call to the backend. Only when the stack property is accessed will the internal representation be converted to a string. Anything else is too expensive. A plain JS object format would be much more useful for development tools developers. jjb ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- erik ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- erik ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Text by me above is hereby placed in the public domain Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Formalize error.stack?
When I started investigating this I had the hope that stack could be standardized. However, the format of the string is cannot be changed without breaking the web so the way forward is to introduce a new property name. But since we are introducing a new property name we should return structured data instead of a plain old string. I haven't had the time to work on this since my initial analysis of the state of the stack property. On Mon, Nov 11, 2013 at 7:51 PM, John Barton johnjbar...@google.com wrote: Note that in Chrome the devtools are remote and error.stack is a getter which issues a remote method call to the backend. Only when the stack property is accessed will the internal representation be converted to a string. Anything else is too expensive. A plain JS object format would be much more useful for development tools developers. jjb ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- erik ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Formalize error.stack?
The only formatting requirement for the stack property is that if it is present, it must be a string. —Oliver On Nov 12, 2013, at 9:23 AM, Erik Arvidsson erik.arvids...@gmail.com wrote: When I started investigating this I had the hope that stack could be standardized. However, the format of the string is cannot be changed without breaking the web so the way forward is to introduce a new property name. But since we are introducing a new property name we should return structured data instead of a plain old string. I haven't had the time to work on this since my initial analysis of the state of the stack property. On Mon, Nov 11, 2013 at 7:51 PM, John Barton johnjbar...@google.com wrote: Note that in Chrome the devtools are remote and error.stack is a getter which issues a remote method call to the backend. Only when the stack property is accessed will the internal representation be converted to a string. Anything else is too expensive. A plain JS object format would be much more useful for development tools developers. jjb ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- erik ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Formalize error.stack?
See getCWStack() at https://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/debug.js#128 . Of course, we should choose a better name than getCWStack. On the string form, see getStack() at https://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/debug.js#221 . These avoid the information leakage problem of err.stack, since the getStack and getCWStack functions can be denied to untrusted guests, and can only reveal the stacks of errors from their own realm. As with makeWeakRef, we could also provide a combiner to combine multiple getStack functions into one that could unseal the errors from any of the originating realms. On Tue, Nov 12, 2013 at 9:23 AM, Erik Arvidsson erik.arvids...@gmail.comwrote: When I started investigating this I had the hope that stack could be standardized. However, the format of the string is cannot be changed without breaking the web so the way forward is to introduce a new property name. But since we are introducing a new property name we should return structured data instead of a plain old string. I haven't had the time to work on this since my initial analysis of the state of the stack property. On Mon, Nov 11, 2013 at 7:51 PM, John Barton johnjbar...@google.comwrote: Note that in Chrome the devtools are remote and error.stack is a getter which issues a remote method call to the backend. Only when the stack property is accessed will the internal representation be converted to a string. Anything else is too expensive. A plain JS object format would be much more useful for development tools developers. jjb ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- erik ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Formalize error.stack?
On Tue, Nov 12, 2013 at 12:35 PM, Oliver Hunt oli...@apple.com wrote: The only formatting requirement for the stack property is that if it is present, it must be a string. No. There is a lot of code out there that parses this string and depend on the format. See Mark's reply for one such case. —Oliver On Nov 12, 2013, at 9:23 AM, Erik Arvidsson erik.arvids...@gmail.com wrote: When I started investigating this I had the hope that stack could be standardized. However, the format of the string is cannot be changed without breaking the web so the way forward is to introduce a new property name. But since we are introducing a new property name we should return structured data instead of a plain old string. I haven't had the time to work on this since my initial analysis of the state of the stack property. On Mon, Nov 11, 2013 at 7:51 PM, John Barton johnjbar...@google.comwrote: Note that in Chrome the devtools are remote and error.stack is a getter which issues a remote method call to the backend. Only when the stack property is accessed will the internal representation be converted to a string. Anything else is too expensive. A plain JS object format would be much more useful for development tools developers. jjb ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- erik ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- erik ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Formalize error.stack?
Righto, do we know whether Carakan/V8’s text or SM’s text is preferred? Currently it seems like JSC’s is a little bit weird compare to others, and as i’ve said earlier i’m happy to change it to match another engine (we all have the same info in varying ways, so we can all technically produce the same view in our .stack string) —Oliver On Nov 12, 2013, at 11:17 AM, Erik Arvidsson erik.arvids...@gmail.com wrote: On Tue, Nov 12, 2013 at 12:35 PM, Oliver Hunt oli...@apple.com wrote: The only formatting requirement for the stack property is that if it is present, it must be a string. No. There is a lot of code out there that parses this string and depend on the format. See Mark's reply for one such case. —Oliver On Nov 12, 2013, at 9:23 AM, Erik Arvidsson erik.arvids...@gmail.com wrote: When I started investigating this I had the hope that stack could be standardized. However, the format of the string is cannot be changed without breaking the web so the way forward is to introduce a new property name. But since we are introducing a new property name we should return structured data instead of a plain old string. I haven't had the time to work on this since my initial analysis of the state of the stack property. On Mon, Nov 11, 2013 at 7:51 PM, John Barton johnjbar...@google.com wrote: Note that in Chrome the devtools are remote and error.stack is a getter which issues a remote method call to the backend. Only when the stack property is accessed will the internal representation be converted to a string. Anything else is too expensive. A plain JS object format would be much more useful for development tools developers. jjb ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- erik ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- erik ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: Formalize error.stack?
I think V8's is preferred. IE10 adopted it, and there's a lot of stack-parsing going on in Node.js land. If SpiderMonkey and JSC would come around to that, it would be lovely. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Formalize error.stack?
FWIW, the code I linked to, which arv refers to, when it finds itself on SM, normalizes the SM error stack string to approx v8's format. But the more important part of the answer is the parsed form provided by getCWStack. On Tue, Nov 12, 2013 at 12:20 PM, Oliver Hunt oli...@apple.com wrote: Righto, do we know whether Carakan/V8’s text or SM’s text is preferred? Currently it seems like JSC’s is a little bit weird compare to others, and as i’ve said earlier i’m happy to change it to match another engine (we all have the same info in varying ways, so we can all technically produce the same view in our .stack string) —Oliver On Nov 12, 2013, at 11:17 AM, Erik Arvidsson erik.arvids...@gmail.com wrote: On Tue, Nov 12, 2013 at 12:35 PM, Oliver Hunt oli...@apple.com wrote: The only formatting requirement for the stack property is that if it is present, it must be a string. No. There is a lot of code out there that parses this string and depend on the format. See Mark's reply for one such case. —Oliver On Nov 12, 2013, at 9:23 AM, Erik Arvidsson erik.arvids...@gmail.com wrote: When I started investigating this I had the hope that stack could be standardized. However, the format of the string is cannot be changed without breaking the web so the way forward is to introduce a new property name. But since we are introducing a new property name we should return structured data instead of a plain old string. I haven't had the time to work on this since my initial analysis of the state of the stack property. On Mon, Nov 11, 2013 at 7:51 PM, John Barton johnjbar...@google.com wrote: Note that in Chrome the devtools are remote and error.stack is a getter which issues a remote method call to the backend. Only when the stack property is accessed will the internal representation be converted to a string. Anything else is too expensive. A plain JS object format would be much more useful for development tools developers. jjb ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- erik ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- erik ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Text by me above is hereby placed in the public domain Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Formalize error.stack?
Righto, filed https://bugs.webkit.org/show_bug.cgi?id=124220 —Oliver On Nov 12, 2013, at 12:30 PM, Mark Miller erig...@gmail.com wrote: FWIW, the code I linked to, which arv refers to, when it finds itself on SM, normalizes the SM error stack string to approx v8's format. But the more important part of the answer is the parsed form provided by getCWStack. On Tue, Nov 12, 2013 at 12:20 PM, Oliver Hunt oli...@apple.com wrote: Righto, do we know whether Carakan/V8’s text or SM’s text is preferred? Currently it seems like JSC’s is a little bit weird compare to others, and as i’ve said earlier i’m happy to change it to match another engine (we all have the same info in varying ways, so we can all technically produce the same view in our .stack string) —Oliver On Nov 12, 2013, at 11:17 AM, Erik Arvidsson erik.arvids...@gmail.com wrote: On Tue, Nov 12, 2013 at 12:35 PM, Oliver Hunt oli...@apple.com wrote: The only formatting requirement for the stack property is that if it is present, it must be a string. No. There is a lot of code out there that parses this string and depend on the format. See Mark's reply for one such case. —Oliver On Nov 12, 2013, at 9:23 AM, Erik Arvidsson erik.arvids...@gmail.com wrote: When I started investigating this I had the hope that stack could be standardized. However, the format of the string is cannot be changed without breaking the web so the way forward is to introduce a new property name. But since we are introducing a new property name we should return structured data instead of a plain old string. I haven't had the time to work on this since my initial analysis of the state of the stack property. On Mon, Nov 11, 2013 at 7:51 PM, John Barton johnjbar...@google.com wrote: Note that in Chrome the devtools are remote and error.stack is a getter which issues a remote method call to the backend. Only when the stack property is accessed will the internal representation be converted to a string. Anything else is too expensive. A plain JS object format would be much more useful for development tools developers. jjb ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- erik ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- erik ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Text by me above is hereby placed in the public domain Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Formalize error.stack?
Note that in Chrome the devtools are remote and error.stack is a getter which issues a remote method call to the backend. Only when the stack property is accessed will the internal representation be converted to a string. Anything else is too expensive. A plain JS object format would be much more useful for development tools developers. jjb ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Formalize error.stack?
FWIW, I think it would be really cool if this property's behavior was standardized. -Filip On Nov 9, 2013, at 4:50 PM, Nicholas C. Zakas standa...@nczconsulting.com wrote: Reading through the recent ES draft, I was surprised to see that there is no definition for the stack instance property on Error or NativeError. This is supported in all browsers (including IE 10+) and Node.js, and it seems like it's supported in a reasonably consistent way that would lend itself to formal definition. Is this a spec oversight or is the exclusion intentional? Thanks. -- ___ Nicholas C. Zakas http://www.nczonline.net ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Formalize error.stack?
Here is the current work http://wiki.ecmascript.org/doku.php?id=strawman:error_stack On Sat, Nov 9, 2013 at 7:50 PM, Nicholas C. Zakas standa...@nczconsulting.com wrote: Reading through the recent ES draft, I was surprised to see that there is no definition for the stack instance property on Error or NativeError. This is supported in all browsers (including IE 10+) and Node.js, and it seems like it's supported in a reasonably consistent way that would lend itself to formal definition. Is this a spec oversight or is the exclusion intentional? Thanks. -- ___ Nicholas C. Zakas http://www.nczonline.net ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Formalize error.stack?
I think there’s a comment on that page to the effect of “it has to be a
string”, i think amazon was one of the sites that interpret the existence of
.stack as implying it’s a string.
All things being equal i think that i prefer the current Carakan/V8 string
format, and would be happy to change JSC’s message to that.
As far as eager vs. late creation, I’ve seen - and recall from Java - that
people try to get a stack trace with (new Error).stack, which i guess is an
argument for creation with the error object. On the other hand appending
.stack to an arbitrary object on throw means anything can have a stack trace
(this is what JSC does). Despite the “yay whatever object i want” advantage,
as time has gone by i’ve found myself feeling that appending at Error
construction is a better model and would not be opposed to that being the
standard.
That said the “new Error().stack” or in JSC try {throw {}}catch(e){e.stack}”
(woo concise!) construct is sufficiently common that i think we should provide
a decent stack introspection API, as terrible as that idea is :(
My main concern with that is that it could expose implementation specific
details (though not necessarily as bad as .caller).
—Oliver
On Nov 9, 2013, at 5:04 PM, Rick Waldron waldron.r...@gmail.com wrote:
Here is the current work
http://wiki.ecmascript.org/doku.php?id=strawman:error_stack
On Sat, Nov 9, 2013 at 7:50 PM, Nicholas C. Zakas
standa...@nczconsulting.com wrote:
Reading through the recent ES draft, I was surprised to see that there is no
definition for the stack instance property on Error or NativeError. This is
supported in all browsers (including IE 10+) and Node.js, and it seems like
it's supported in a reasonably consistent way that would lend itself to
formal definition.
Is this a spec oversight or is the exclusion intentional?
Thanks.
--
___
Nicholas C. Zakas
http://www.nczonline.net
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Formalize error.stack?
On 11/9/13 7:50 PM, Nicholas C. Zakas wrote: it seems like it's supported in a reasonably consistent way that would lend itself to formal definition. It's not as consistent as you would think, especially once you have stacks crossing C++ code (think dispatchEvent() or Array.prototype.map), stacks crossing globals, stacks across things that spin the event loop in various ways (showModalDialog, sync XHR), stacks across different trust domains. It would still be good to standardize this, but I don't expect it to be easy to do so... -Boris ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
