Error stack

Domenic Denicola domenic at
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.


From: es-discuss-bounces at [es-discuss-bounces at] on behalf of Erik Arvidsson [erik.arvidsson at]
Sent: Thursday, June 07, 2012 16:39
To: Jason Orendorff
Cc: es-discuss at
Subject: Re: Error stack

On Thu, Jun 7, 2012 at 1:12 PM, Jason Orendorff
<jason.orendorff at> 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 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

> 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?)

es-discuss mailing list
es-discuss at

More information about the es-discuss mailing list