I think it is for you to decide what makes most sense, but whatever decision
is made I think the stack trace shown in the debugger (and devtools) should
contain the same frames as the stacktraces produced
by Runtime_CollectStackTrace. From the tests in test/mjsunit/stack-traces.js
it seems as if having frames from native JS makes sense, e.g.
function testArrayNative() {
[1, 2, 3].map(function () { FAIL; });
}
function testImplicitConversion() {
function Nirk() { }
Nirk.prototype.valueOf = function () { FAIL; };
return 1 + (new Nirk);
}
/Søren
On Mon, Feb 1, 2010 at 11:28, <[email protected]> wrote:
> I could prepare another change that changes exception stack trace behavior
> if we
> agree that it's the right approach.
>
>
> On 2010/02/01 10:27:40, Yury Semikhatsky wrote:
>
>> Runtime_CollectStackTrace doesn't use StackTraceFrameIterator and is not
>> affected by this change. I'm not sure if we want to exclude all the frames
>>
> with
>
>> functions from native scripts. If we want to do so, we could probably use
>> StackTraceFrameIterator instead of StackFrameIterator in
>> Runtime_CollectStackTrace. Probably it's not that bad to show builtin
>>
> functions
>
>> in the stack trace since in the case of stack trace user is still able to
>>
> track
>
>> the source of error (unlike error message handler where the stack may not
>> be
>> available).
>>
>
> On 2010/02/01 09:21:20, Søren Gjesse wrote:
>> > LGTM
>> >
>> > Consider adding a test to tets/mjsunit/stack-traces.js as well.
>>
>
>
>
> http://codereview.chromium.org/555170
>
--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
