Error stack

[Brendan Eich]

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 <oliver at apple.com 
>> <mailto: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.
>>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss