Error stack

Domenic Denicola domenic at domenicdenicola.com
Thu Jun 7 14:47:22 PDT 2012


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



More information about the es-discuss mailing list