Error stack

[Oliver Hunt]

There's no real consistency between any implementations of .stack.  The only reason it needs to be a string is so that sites that blindly use .split() on it don't throw an exception.

If you used JSON you could do the following output:
{"message":"...","trace":[
{"source":"...", line:...},
{"source":"...", line:...},
{"source":"...", line:...},
...
]}

.split("\n") would provide a analogous result to the equivalent on current formats, with the added advantage of having automatically escaped anything that needs escaping (so each line in the trace would be guaranteed to be one line.

Better yet, because you're just saying "use JSON" it becomes perfectly possible to add additional fields (function name, inferred name, arguments, type,... whatever) without requiring re-specifying the format, or trying to add new fields without breaking existing parsers.

Note: this is just if we wanted to use .stack -- my original implementation was prefixed and just produced an array iirc, but i was convinced to use .stack so sites wouldn't have to manually select the stack property to use.  This then broke many big sites that always do .split() on .stack, which didn't work as the result was not a string.  Yay!

--Oliver

On Jun 10, 2012, at 2:49 PM, T.J. Crowder wrote:

> On 10 June 2012 22:44, Oliver Hunt <oliver at apple.com> wrote:
> My original implementation in JSC was as an Array, but I found that there were sites that depended on .stack being a string if it was present.  Any form of string encoding we expect to be machine parseable by necessity will require escaping and full format description.  I've actually been tempted to switch JSC's current icky format into JSON on the basis that JSON is already well defined, and everyone has fast encoders and decoders for JSON these days.
> 
> Wouldn't changing the existing format of the string break existing code without offering any real benefit over continuing the existing format of that string (for now) but adding a new structured property that code could take advantage of? Not seeing much point in the browser generating JSON that just has to be decoded by anyone who wants to use it (fast or not).
> 
> -- T.J. 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120610/573f87a6/attachment-0001.html>