On 2014/08/13 11:22:03, aandrey wrote:
https://codereview.chromium.org/461023002/diff/1/test/mjsunit/es6/throw-caught-by-default-reject-handler.js
File test/mjsunit/es6/throw-caught-by-default-reject-handler.js (right):
https://codereview.chromium.org/461023002/diff/1/test/mjsunit/es6/throw-caught-by-default-reject-handler.js#newcode50
test/mjsunit/es6/throw-caught-by-default-reject-handler.js:50: // p2 is
rejected
by p1's default reject handler.
On 2014/08/13 11:13:49, Yang wrote:
> On 2014/08/13 11:03:04, aandrey wrote:
> > do we want the debugger to stop twice in this example?
>
> I'm not sure. Maybe we should suppress rejections from the default
reject
> handler?
I'm not sure either, but DevTools will ignore pauses if frameCount == 0
anyway.
Not sure about error messaging though.
In the test with returning Promise.reject() I think we should give a
chance
for
DevTools to stop. If we have frameCount == 0 in both cases, we won't stop
obviously... Would be great to stop at return point after returning a
possibly-unhandled rejected promise.
On other thought, this behavior may be fine. We don't stop debugger on
syntax
errors for example.
https://codereview.chromium.org/461023002/
--
--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
