On Thu, Mar 27, 2014 at 9:11 AM, Erik Arvidsson <erik.arvidsson at gmail.com>wrote:

> To be clear. Changing .stack is not an option. We need to introduce a new
> API.
>
> On Tue Mar 25 2014 at 4:40:20 PM, John Lenz <concavelenz at gmail.com> wrote:
>
>> Interesting sourcemap usage.  But is there any hope for standardization
>> of the existing stack handling for ES7? It wasn't clear to me why it
>> stalled for ES6.  There a few things I would like to see:
>> 1) standardization V8's Error.captureStackTrace API
>>
>
> The V8 API has some issues that it returns objects (getThis, getFunction
> and getEvalOrigin). For security reasons we would want to limit what the
> API gives you to names and locations.
>

I think you mean prepareStackTrace here.  "captureStackTrace" allows you
apply the stack trace while ignoring zero or more known methods in the call
stack.


>
>
>> 2) standardization of the stack format
>>
>
> We can probably reuse V8's and Chakra's toString format here.
>

That would be awesome by itself.


>
>
>> 3) standardizaton of when the stack is added to the Error object
>> (creation vs throw)
>>
>
> Since we have to do a new API we can decide either way. Personally I
> prefer at creation maybe there are some performance benefits to only add it
> on throw?
>

If "prepareStackTrace" is available and can reset a stack trace, adding it
on throw if not set seems sufficient.


>
>
>> 4) specification as to whether throw (and re-throw) overwrite any
>> existing stack property
>>
>
> Same here. New API. What is the desired behavior?
>

If "prepareStackTrace" is available and can reset a stack trace, adding it
on rethrow if not set seems sufficient.  I haven't looked at existing
behavior.


>
>>
>> More would be welcome but that is what I would actually have an immediate
>> use for.
>>
>>
>>
>>
>> On Tue, Mar 25, 2014 at 11:43 AM, Mark S. Miller <erights at google.com>wrote:
>>
>>> Hi John, see also my message at <
>>> https://mail.mozilla.org/pipermail/es-discuss/2014-March/036642.html>
>>> which cites some of your work on sourcemaps.
>>>
>>>
>>> On Tue, Mar 25, 2014 at 11:25 AM, Rick Waldron <waldron.rick at gmail.com>wrote:
>>>
>>>>
>>>>
>>>>
>>>> On Tue, Mar 25, 2014 at 1:38 PM, John Lenz <concavelenz at gmail.com>wrote:
>>>>
>>>>> I was recently modifying some code to be strict mode compliant and it
>>>>> reminded me that the primary use of the Function caller property and
>>>>> arguments.caller is to build stack traces.   Now the latest Internet
>>>>> Explorer releases have support for stack traces, as of course do Chrome,
>>>>> FF, and Safari but only Chrome/V8, to my knowledge, has an actual API.
>>>>>
>>>>> I know there was some initial work in this area and nothing is likely
>>>>> to happen in the ES6 time frame but can something to be done to make the
>>>>> stacks traces more usable?
>>>>>
>>>>
>>>> Take a look at the work Erik Arvidsson has done so far:
>>>>
>>>> http://wiki.ecmascript.org/doku.php?id=strawman:error_stack
>>>>
>>>>
>>>> Rick
>>>>
>>>>
>>>> _______________________________________________
>>>> es-discuss mailing list
>>>> es-discuss at mozilla.org
>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>
>>>>
>>>
>>>
>>> --
>>>     Cheers,
>>>     --MarkM
>>>
>>
>> _______________________________________________
>> 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/20140327/b91d8a80/attachment.html>

On Thu, Mar 27, 2014 at 9:11 AM, Erik Arvidsson <erik.arvidsson at gmail.com>wrote:

> The V8 API has some issues that it returns objects (getThis, getFunction
> and getEvalOrigin). For security reasons we would want to limit what the
> API gives you to names and locations.

I think you mean prepareStackTrace here.  "captureStackTrace" allows you
apply the stack trace while ignoring zero or more known methods in the call
stack.

> We can probably reuse V8's and Chakra's toString format here.

That would be awesome by itself.

> Since we have to do a new API we can decide either way. Personally I
> prefer at creation maybe there are some performance benefits to only add it
> on throw?

If "prepareStackTrace" is available and can reset a stack trace, adding it
on throw if not set seems sufficient.

> Same here. New API. What is the desired behavior?

If "prepareStackTrace" is available and can reset a stack trace, adding it
on rethrow if not set seems sufficient.  I haven't looked at existing
behavior.