Maximally minimal stack trace standardization

John Lenz concavelenz at gmail.com
Sat Mar 7 22:55:57 UTC 2015


I wanted to ping this thread and see how we could get "max-min stack
traces" to the next step?

On Fri, Oct 10, 2014 at 11:47 AM, Frankie Bagnardi <f.bagnardi at gmail.com>
wrote:

> I think this is a great idea.  I often use stack traces, especially in
> node.js, for debug error messages and logging.  This would make it much
> simpler to work with them.
>
> Also there are some libraries which end up with a lot of wrapped
> functions, which could be omitted using an error cleaner function.
>
> I suggest a stackTrace property (getter, no write) of Error objects:
>
>  - .frames is an array of stack frame metadata objects
>  - no concept of sourcemaps
>  - [[ToString]] is left implementation dependant, allowing them to add
> information from sourcemaps, or otherwise customize it
>
> This allows for a programmable api, and a human readable version.  Also
> devtools and other code applications (like Carl Smith's) can create rich
> UIs for this data.
>
> I'm sure the smart people at TC39 can come up with a good (or good enough)
> way to represent PTCs.
>
>
>
> On Sat, Oct 4, 2014 at 9:31 AM, John Lenz <concavelenz at gmail.com> wrote:
>
>> Is ES6 "shipping" PTCs without implementer feedback? Or how have those
>> that tried dealt with stack traces?
>> On Sep 29, 2014 3:20 PM, "John Lenz" <concavelenz at gmail.com> wrote:
>>
>>> What does TC39 expect with regard to PTC and the
>>> standard-because-everyone-has-one "stack" property?   Has any of the VMs
>>> actually tried to implement PTC for JS?
>>>
>>> On Mon, Sep 29, 2014 at 12:02 PM, Brendan Eich <brendan at mozilla.org>
>>> wrote:
>>>
>>>> Allen Wirfs-Brock wrote:
>>>>
>>>>> No particular reason an implementation can't optimize through that if
>>>>> they want to.
>>>>>
>>>>
>>>> The question is whether it should be normative. PTC is about observable
>>>> asymptotic space performance (I keep saying :-P).
>>>>
>>>> /be
>>>>
>>>> _______________________________________________
>>>> es-discuss mailing list
>>>> es-discuss at mozilla.org
>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>
>>>
>>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150307/b5d609f8/attachment.html>


More information about the es-discuss mailing list