domenic at domenicdenicola.com (2013-11-13T17:21:01.456Z)
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).
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.rick at 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 <standards at 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 at mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > > _______________________________________________ > es-discuss mailing list > es-discuss at mozilla.org > https://mail.mozilla.org/listinfo/es-discuss -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20131109/ee423a80/attachment.html>