Formalize error.stack?
FWIW, I think it would be really cool if this property's behavior was standardized.
Here is the current work strawman: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).
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...
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.
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.
The only formatting requirement for the stack property is that if it is present, it must be a string.
See getCWStack().
Of course, we should choose a better name than getCWStack.
On the string form, see getStack().
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 12:35 PM, Oliver Hunt <oliver at 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.
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)
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.
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.
Righto, filed bugs.webkit.org/show_bug.cgi?id=124220
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.
Column numbers are essential.
John Lenz wrote:
Column numbers are essential.
Yes! Can't forget those. Anything else source-map related?
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?