Error stack

[Charles Kendrick]

I agree that something like error.stackFrames would be ideal.  However
I would say the V8 stack trace API is missing 3 key things:

1. access to parameter values
2. access to local variables defined in the function
3. access to the line of code that crashed / called the next frame
without having to go download the source file and use the line number
to find it.  This is even more important for generated / eval()'d code
where there is no source file per se.

Note that access to the function for the frame via getFunction() is
inadequate - doesn't work with recursion.  APIs to get local variables
and parameter values would need to be on the stackFrame.

P.S. fascinating to learn that Node.js does long traces, we have done
the same in SmartClient for a long time.

On Thu, Jun 7, 2012 at 2:47 PM, Domenic Denicola
<domenic at domenicdenicola.com> wrote:
> Machine-parsability might be reaching too far, especially if you lose the benefits of nice function/method name inference. Instead, perhaps a separate strawman to standardize something like the V8 stack trace API [1]?
>
> It is used in Node for providing long stack traces [2], [3], [4]. It's a bit cumbersome, e.g. maybe a separate error.stackFrames getter would be nicer and the Java-style getFileName() methods could become simple properties. But the fact that it exists is extremely useful.
>
> [1]: http://code.google.com/p/v8/wiki/JavaScriptStackTraceApi
> [2]: https://github.com/tlrobinson/long-stack-traces
> [3]: https://github.com/kriskowal/q/blob/0c1ffdc50bbbba6ea77c3e97075fab35ab9f7b2d/q.js#L261-405, https://github.com/kriskowal/q/blob/0c1ffdc50bbbba6ea77c3e97075fab35ab9f7b2d/q.js#L1307-1321
> [4]: https://github.com/NobleJS/WinningJS-todo/commit/2d4ca10c4f672dac9f021b697c4c72bbff321ed9
>
> ________________________________________
> From: es-discuss-bounces at mozilla.org [es-discuss-bounces at mozilla.org] on behalf of Erik Arvidsson [erik.arvidsson at gmail.com]
> Sent: Thursday, June 07, 2012 16:39
> To: Jason Orendorff
> Cc: es-discuss at mozilla.org
> Subject: Re: Error stack
>
> On Thu, Jun 7, 2012 at 1:12 PM, Jason Orendorff
> <jason.orendorff at gmail.com> wrote:
>> This isn't machine parseable in all cases, since the .message may
>> contain newlines and can end with something like "\n  at ..."
>
> That is a good point. This also applies to the "name" of a function
> (and object when included). It is trivial to create a function "name"
> that breaks the V8 style formatting. SpiderMonkey "gets" away with
> this by using the name of the function expression and it does not try
> to deduce a name based on the code..
>
> window['\n@'] = function() {
>  alert(new Error().stack);
> };
>
> When I first set out to write the proposal I was set on the
> SpiderMonkey formatting but as I researched this I drifted closer and
> closer to the V8 formatting. The thing that convinced me was eval.
>
> I also don't think that providing ErrorName: ErrorMessage is a hard
> requirement. The same information is already available using
> errorObject.name and errorObject.message.
>
> If we remove the first line and require that non identifiers are
> quoted I think we can guarantee that the value is machine parseable
> again.
>
>> Changing this in Firefox would affect any Firefox addons that use
>> Error.stack, but maybe we can take that hit.
>
> For web apps we already have to parse two different versions so I'm
> not too concerned about that case. The WebKit mobile web does not
> depend on either format (Safari doesn't have it in any shipping
> version yet) so the two problematic big eco systems are Firefox and
> Chrome extensions (and Node.js?)
>
> --
> erik
> _______________________________________________
> 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