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-boun...@mozilla.org [es-discuss-boun...@mozilla.org] on behalf of Erik Arvidsson [erik.arvids...@gmail.com] Sent: Thursday, June 07, 2012 16:39 To: Jason Orendorff Cc: es-discuss@mozilla.org Subject: Re: Error stack On Thu, Jun 7, 2012 at 1:12 PM, Jason Orendorff <jason.orendo...@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@mozilla.org https://mail.mozilla.org/listinfo/es-discuss _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
