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.
>

+1.


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

I think that's a good place to start, and <
https://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/debug.js#158>
attempts to normalize other browsers to the v8 format. However, in doing so
we discovered that FF Nightly 30 includes useful extra information,
regarding nested eval contexts, which this code throws away with the
"FFEvalLineColPatterns" regexp. Before adopting the v8 format, we should
discuss whether this extra information is useful enough that we should find
a way to keep it. Mozillians, why did you add this extra information?

Also, rather than startline/startcolumn, we should really do what Smalltalk
has done forever: startline/startcolumn/endline/endcolumn.



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

The stack should not be accessible given only the error object. Rather,
there should be a getStack function <
https://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/debug.js#300>
which, given an error object, returns the stack. That way, code which does
not have access to the getStack function cannot see the stacks.


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


-- 
Text by me above is hereby placed in the public domain

  Cheers,
  --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140327/e9fed8cd/attachment-0001.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.

+1.

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

I think that's a good place to start, and https://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/debug.js#158 attempts to normalize other browsers to the v8 format. However, in doing so
we discovered that FF Nightly 30 includes useful extra information,
regarding nested eval contexts, which this code throws away with the
"FFEvalLineColPatterns" regexp. Before adopting the v8 format, we should
discuss whether this extra information is useful enough that we should find
a way to keep it. Mozillians, why did you add this extra information?

Also, rather than startline/startcolumn, we should really do what Smalltalk
has done forever: startline/startcolumn/endline/endcolumn.

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

The stack should not be accessible given only the error object. Rather,
there should be a [getStack function](https://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/debug.js#300) which, given an error object, returns the stack. That way, code which does
not have access to the getStack function cannot see the stacks.