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 <oli...@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.
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
