Comment #66 on issue 3093 by espr...@chromium.org: Debugging promises
https://code.google.com/p/v8/issues/detail?id=3093
Just add a no-op catch handler.
function silentReject(error) {
var result = Promise.reject(error);
result.catch(function() { });
return result;
}
--
You received
Comment #65 on issue 3093 by mi...@zoltu.net: Debugging promises
https://code.google.com/p/v8/issues/detail?id=3093
How do I disable this? My logs are full of these errors even though they
aren't errors because I create some promises in a rejected state
intentionally (so future reads can
Updates:
Status: Fixed
Comment #63 on issue 3093 by aand...@chromium.org: Debugging promises
https://code.google.com/p/v8/issues/detail?id=3093
(No comment was entered for this change.)
--
You received this message because this project is configured to send all
issue notifications to
Comment #64 on issue 3093 by espr...@chromium.org: Debugging promises
https://code.google.com/p/v8/issues/detail?id=3093
Thanks so much for fixing this, it's made developers much happier.
--
You received this message because this project is configured to send all
issue notifications to this
Comment #62 on issue 3093 by bugdro...@chromium.org: Debugging promises
https://code.google.com/p/v8/issues/detail?id=3093#c62
The following revision refers to this bug:
https://chromium.googlesource.com/v8/v8.git/+/e68e62c8917405e33155965303bb263fae68fcb0
commit
Updates:
Cc: yu...@chromium.org
Comment #61 on issue 3093 by yang...@chromium.org: Debugging promises
https://code.google.com/p/v8/issues/detail?id=3093
With my CL to report unhandled rejected promises [0] results in something
shown in the attached screenshot.
Obviously we still
Comment #57 on issue 3093 by bugdro...@chromium.org: Debugging promises
http://code.google.com/p/v8/issues/detail?id=3093#c57
The following revision refers to this bug:
https://chromium.googlesource.com/external/v8.git/+/0ae0b81cdbadf5ad0448a1871df0737e38eabf02
commit
Comment #58 on issue 3093 by dome...@domenicdenicola.com: Debugging promises
http://code.google.com/p/v8/issues/detail?id=3093
Ignore default reject handler when looking for reject handlers.
I don't know exactly what implementation strategy you guys are pursuing, so
I could be wrong, but I
Comment #59 on issue 3093 by yang...@chromium.org: Debugging promises
http://code.google.com/p/v8/issues/detail?id=3093
@#58:
Default reject handlers should count as toward being handled, I agree. But,
consider this:
var p = new Promise() {
throw new Error();
}
var q = p.then(function()
Comment #60 on issue 3093 by dome...@domenicdenicola.com: Debugging promises
http://code.google.com/p/v8/issues/detail?id=3093
@#59:
OK, I guess I was focused too much on the displaying-unhandled-rejections
feature, and not on the when-to-break feature. Sounds like you have things
well in
Comment #51 on issue 3093 by aand...@chromium.org: Debugging promises
http://code.google.com/p/v8/issues/detail?id=3093
The following will neither stop on uncaught exceptions, not print anything
to DevTools console.
var resolve, reject;
var p = new Promise(function(_resolve, _reject) {
Comment #52 on issue 3093 by aand...@chromium.org: Debugging promises
http://code.google.com/p/v8/issues/detail?id=3093
In the example #51, the second then gives a false impression of catching
exceptions from the previous promise. We should check that the
promiseOnReject handler is
Comment #53 on issue 3093 by nison.m...@gmail.com: Debugging promises
http://code.google.com/p/v8/issues/detail?id=3093
I don't understand: in the #51, there is no rejection handler (which is
what you say in #52), why would the exception be ignored by the DevTools?
--
You received this
Updates:
Labels: -Priority-Medium Priority-High
Comment #54 on issue 3093 by aand...@chromium.org: Debugging promises
http://code.google.com/p/v8/issues/detail?id=3093
@yangguo,
DevTools no longer prints exception messages upon promise exceptions. This
seems to be a regression after
Comment #55 on issue 3093 by yang...@chromium.org: Debugging promises
http://code.google.com/p/v8/issues/detail?id=3093
To document what we discussed:
#54 would be a feature request. Rejections are only treated the same as
throws wrt exception debug events. Wrt Javascript execution, they are
Comment #56 on issue 3093 by yang...@chromium.org: Debugging promises
http://code.google.com/p/v8/issues/detail?id=3093
#51 works fine in V8, with a small twist:
the first then actually adds a default reject handler, as it's not provided
as second argument. That default reject handler simply
Comment #50 on issue 3093 by yang...@chromium.org: Debugging promises
http://code.google.com/p/v8/issues/detail?id=3093
So, as described in Chromium issue 393913, with r22913, rejecting Promises
triggers an exception debug event just like throwing in Promises. Just like
throwing, they can
Comment #49 on issue 3093 by o...@chromium.org: Debugging promises
http://code.google.com/p/v8/issues/detail?id=3093
I still think we're killing the 99% use-case for the 1% use-case. We should
take this discussion to the appropriate standards body. Where is this being
discussed/specced?
Issue 3093: Debugging promises
http://code.google.com/p/v8/issues/detail?id=3093
This issue is now blocking issue chromium:393913.
See http://code.google.com/p/chromium/issues/detail?id=393913
--
You received this message because you are listed in the owner
or CC fields of this issue, or
Comment #47 on issue 3093 by rossb...@google.com: Debugging promises
http://code.google.com/p/v8/issues/detail?id=3093
Nit: no need for a contortion, really: since you can chain multiple
handlers to one promise, the simpler way would be to keep the late chaining
as you desire, but just also
Comment #39 on issue 3093 by dome...@domenicdenicola.com: Debugging promises
http://code.google.com/p/v8/issues/detail?id=3093
The use-case of explicitly wanting to add rejections after the fact
seems really niche to me.
Let me assure you that, having written many, many promise-using
Comment #40 on issue 3093 by o...@chromium.org: Debugging promises
http://code.google.com/p/v8/issues/detail?id=3093
Unlogging just sounds like a bad user experience to me. If you have the
console open you'd see the error flicker by.
But, even that aside, a pure-devtools based solution is
Comment #41 on issue 3093 by dome...@domenicdenicola.com: Debugging promises
http://code.google.com/p/v8/issues/detail?id=3093
Oh, and I forgot to add: I understand your frustration. I think shipping
promises as-is is equivalent to shipping a JS engine without a debugger or
any indication
Comment #42 on issue 3093 by yang...@chromium.org: Debugging promises
http://code.google.com/p/v8/issues/detail?id=3093
Wow. Huge thread over night.
So here's the current state:
When an exception is thrown in a promise, it would be swallowed and
forwarded to the (possibly not yet)
Comment #43 on issue 3093 by rossb...@chromium.org: Debugging promises
http://code.google.com/p/v8/issues/detail?id=3093
What Yang says, and the devtools team is working on it.
As for unlogging, that seems like an oxymoron to me. AFAIAC a log is a
monotonically growing history of events, not
Comment #44 on issue 3093 by johnjbar...@google.com: Debugging promises
http://code.google.com/p/v8/issues/detail?id=3093
Breakpoint debugging relies on, well, breakpointing. Thus any solution to
this fundamental problem of promises within a breakpoint debugger has to
result in the
Comment #45 on issue 3093 by o...@chromium.org: Debugging promises
http://code.google.com/p/v8/issues/detail?id=3093
I'm glad devtools work is being done here, but I still don't think that's
sufficient. We need platform-exposed changes here as well. Web sites need
to be able to log stack
Comment #46 on issue 3093 by dome...@domenicdenicola.com: Debugging promises
http://code.google.com/p/v8/issues/detail?id=3093
Any case where you prefetch data often decouples the handling of a
rejection from the time the promise was rejected, since you only
`.then(...)` the promise when
Updates:
Cc: aba...@chromium.org espr...@chromium.org
Comment #34 on issue 3093 by espr...@chromium.org: Debugging promises
http://code.google.com/p/v8/issues/detail?id=3093
Issue chromium:387505 has been merged into this issue.
--
You received this message because this project is
Comment #35 on issue 3093 by espr...@chromium.org: Debugging promises
http://code.google.com/p/v8/issues/detail?id=3093
What's the status of this? Using Promises is incredibly painful right now.
--
You received this message because this project is configured to send all
issue notifications
Comment #36 on issue 3093 by o...@chromium.org: Debugging promises
http://code.google.com/p/v8/issues/detail?id=3093
Finding a way where we log to the console if there's no rejection handler
is crucial. I understand that there are use-cases where you might not want
that, but the current
Comment #37 on issue 3093 by dome...@domenicdenicola.com: Debugging promises
http://code.google.com/p/v8/issues/detail?id=3093
It's fine to log if there's an unhandled rejection, as long as you *unlog*
it once the rejection becomes handled. Otherwise the console becomes
useless for entire
Comment #38 on issue 3093 by o...@chromium.org: Debugging promises
http://code.google.com/p/v8/issues/detail?id=3093
Unlogging sounds really complicated to me. The use-case of explicitly
wanting to add rejections after the fact seems really niche to me. We
should support it, but it should
Updates:
Cc: rponn...@chromium.org yhir...@chromium.org
Comment #33 on issue 3093 by yhir...@chromium.org: Debugging promises
http://code.google.com/p/v8/issues/detail?id=3093
Issue chromium:380693 has been merged into this issue.
--
You received this message because this project is
Comment #31 on issue 3093 by jakearch...@google.com: Debugging promises
http://code.google.com/p/v8/issues/detail?id=3093
Yeah, that would work fine in terms of logging errors, but doesn't make
sense for break on error.
--
You received this message because this project is configured to send
Comment #32 on issue 3093 by dome...@domenicdenicola.com: Debugging promises
http://code.google.com/p/v8/issues/detail?id=3093
I'm not sure. From what I can tell the debugger already has some ability
to rewind the stack and break at the point an exception was thrown, even
after the
Comment #30 on issue 3093 by dome...@domenicdenicola.com: Debugging promises
http://code.google.com/p/v8/issues/detail?id=3093
Jake: what libraries like Bluebird do is wait until the end of the turn to
make any decisions about unhandled or not. So in your particular examples:
var p = new
Comment #29 on issue 3093 by jakearch...@chromium.org: Debugging promises
http://code.google.com/p/v8/issues/detail?id=3093
To summarise what I think Domenic is saying:
Break on uncaught exception - Break when a promise without a reject
handler is rejected. This includes rejects triggered
Comment #22 on issue 3093 by mathieu@gmail.com: Debugging promises
http://code.google.com/p/v8/issues/detail?id=3093
Right, but for the dev tools to interrupt at the time the promise is
rejected, the check for unhandled would have to be done at Enqueue time.
As a developer, if the dev
Comment #23 on issue 3093 by yang...@chromium.org: Debugging promises
http://code.google.com/p/v8/issues/detail?id=3093
Not sure if I misunderstand, but
- If a promise is rejected not through throw, but via calling the reject
function, nothing happens.
- At the throw site, we look for the
Comment #24 on issue 3093 by m.go...@gmail.com: Debugging promises
http://code.google.com/p/v8/issues/detail?id=3093
Re #23:
- If a promise is rejected not through throw, but via calling the reject
function, nothing happens.
Why? Shouldn't it behave in the same way as when you throw and not
Comment #25 on issue 3093 by yang...@chromium.org: Debugging promises
http://code.google.com/p/v8/issues/detail?id=3093
Let me try to be clear: none of the behavior here is part of any
specification. It's merely to help developers. The issue here is that
Promises swallow exceptions, and the
Comment #26 on issue 3093 by mathieu@gmail.com: Debugging promises
http://code.google.com/p/v8/issues/detail?id=3093
Sorry I hadn't realized throw and rejections were handled differently. This
is actually counter intuitive when using promises. I would argue the dev
tools should handle
Comment #27 on issue 3093 by dome...@domenicdenicola.com: Debugging promises
http://code.google.com/p/v8/issues/detail?id=3093
Yes, I would strongly suggest treating reject and throw exactly the same.
In both cases an exception is involved; in one case the exception is
communicated via the
Comment #28 on issue 3093 by dome...@domenicdenicola.com: Debugging promises
http://code.google.com/p/v8/issues/detail?id=3093
Forgot to mention: the Canary experience is basically the same as
the blue error stop sign (in the old UI when there was a blue/purple
split, i.e. it is akin to
Comment #19 on issue 3093 by yang...@chromium.org: Debugging promises
http://code.google.com/p/v8/issues/detail?id=3093
In any case, if an exception is caught by a Promise and at the point of
throw it has no reject handler, we will consider it an uncaught exception.
So using pause on
Comment #20 on issue 3093 by mathieu@gmail.com: Debugging promises
http://code.google.com/p/v8/issues/detail?id=3093
@19, That sounds wrong. Imagine the following example:
var p = new Promise(function(resolve, reject) { reject(new Error('Something
went wrong'); });
Comment #21 on issue 3093 by canan...@gmail.com: Debugging promises
http://code.google.com/p/v8/issues/detail?id=3093
@20, the reject function just performs an Enqueue Task (see
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-rejectpromise)
and doesn't immediately reject. So the
Comment #16 on issue 3093 by andsterl...@gmail.com: Debugging promises
http://code.google.com/p/v8/issues/detail?id=3093
(Disclaimer: I work on the JavaScript tools for Microsoft like the F12
tools and Visual Studio debugger.)
We had a similar problem with promises in WinJS wherein catching
Comment #17 on issue 3093 by jakearch...@chromium.org: Debugging promises
http://code.google.com/p/v8/issues/detail?id=3093
This is great insight, thanks!
--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your
Comment #18 on issue 3093 by andsterl...@gmail.com: Debugging promises
http://code.google.com/p/v8/issues/detail?id=3093
Going forward though in VS and F12 we're really relying on the Just My Code
feature so that developers mark files as library and thus don't need to
rely on
Updates:
Status: Assigned
Owner: yang...@chromium.org
Comment #15 on issue 3093 by yang...@chromium.org: Debugging promises
http://code.google.com/p/v8/issues/detail?id=3093
Under review: https://codereview.chromium.org/249503002/
The idea is to provide devtools with a debug
Issue 3093: Debugging promises
http://code.google.com/p/v8/issues/detail?id=3093
This issue is now blocking issue chromium:348919.
See http://code.google.com/p/chromium/issues/detail?id=348919
--
You received this message because you are listed in the owner
or CC fields of this issue, or
Updates:
Cc: amikhayl...@google.com
Comment #13 on issue 3093 by aand...@chromium.org: Debugging promises
http://code.google.com/p/v8/issues/detail?id=3093
(No comment was entered for this change.)
--
You received this message because this project is configured to send all
issue
Updates:
Status: Accepted
Cc: paulir...@chromium.org slightly...@chromium.org aand...@chromium.org
rossb...@chromium.org dslo...@chromium.org
Labels: Harmony Type-FeatureRequest Priority-Medium
Comment #1 on issue 3093 by rossb...@chromium.org: Debugging promises
Comment #2 on issue 3093 by jakearch...@chromium.org: Debugging promises
http://code.google.com/p/v8/issues/detail?id=3093
Works for me. Will keep an eye out for cases where this does the wrong
thing.
--
You received this message because this project is configured to send all
issue
Comment #3 on issue 3093 by jakearch...@chromium.org: Debugging promises
http://code.google.com/p/v8/issues/detail?id=3093
Apparently late-adding catch handers isn't pretty rare
https://github.com/domenic/promises-unwrapping/issues/19#issuecomment-32021399
Not sure what the alternative is
Comment #6 on issue 3093 by stefan.p...@gmail.com: Debugging promises
http://code.google.com/p/v8/issues/detail?id=3093
early example of some tooling ideas + implemention:
https://github.com/tildeio/ember-extension/pull/76
--
You received this message because this project is configured to
Comment #4 on issue 3093 by domenic@lab49.com: Debugging promises
http://code.google.com/p/v8/issues/detail?id=3093
Please do not log unhandled errors to the console immediately, unless there
is a way to *remove* them from the console once they become handled. That
would be a huge
Comment #5 on issue 3093 by dome...@domenicdenicola.com: Debugging promises
http://code.google.com/p/v8/issues/detail?id=3093
Please do not log unhandled errors to the console immediately, unless there
is a way to *remove* them from the console once they become handled. That
would be a huge
Comment #7 on issue 3093 by jakearch...@chromium.org: Debugging promises
http://code.google.com/p/v8/issues/detail?id=3093
What do you think about logging when an end-of-chain rejected promise is
GC'd?
I'm worried about inconsistencies like some errors not being logged for
difficult to
Comment #8 on issue 3093 by dome...@domenicdenicola.com: Debugging promises
http://code.google.com/p/v8/issues/detail?id=3093
Logging upon GC is great! It has no downsides, only upside. It just isn't a
complete solution, since GCs have no obligations to collect promises. I
would definitely
Comment #9 on issue 3093 by jakearch...@chromium.org: Debugging promises
http://code.google.com/p/v8/issues/detail?id=3093
Well, the downsides are providing a potentially confusing log of events, by
logging in the wrong order. I just don't know how bad it would be.
--
You received this
Comment #10 on issue 3093 by dslo...@chromium.org: Debugging promises
http://code.google.com/p/v8/issues/detail?id=3093
Unfortunately logging on GC will kill performance. V8 does not visit
garbage in general, so this will require some sort of finalization
mechanism for promises which is
Comment #11 on issue 3093 by dome...@domenicdenicola.com: Debugging promises
http://code.google.com/p/v8/issues/detail?id=3093
To make sure we're referring to the same GC technique, I am referring to
doing a MakeWeak on the promise and using the callback to log. I imagined
that would be
Comment #12 on issue 3093 by dslo...@chromium.org: Debugging promises
http://code.google.com/p/v8/issues/detail?id=3093
#11: yes, MakeWeak is quite slow (this was one of the motivations for typed
array rewrite as well).
--
You received this message because this project is configured to send
66 matches
Mail list logo
