No commonality is a problem if enough content detects implementations
and depends on each one's .stack. Not sure this is true, just sayin'
(ignoring implementation-specific dependencies, e.g. addons).
The easy way out is Error.prototype.stackTrace, a getter that exposes,
deeply and lazily, objects with string and number valued properties
cleanly reflecting the desired information -- and without any capability
leaks.
At this point, perhaps better is better. Any such stackTrace spec should
not diverge too far from the various .stack implementations, in that one
should be able to construct the latter from the fomer one true
.stackTrace or .stackFrames or whatever it must be called.
/be
Oliver Hunt wrote:
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
<mailto: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
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
