, June 17, 2015 14:40
To: wha...@whatwg.org; Domenic Denicola
Subject: Re: [whatwg] An API for unhandled promise rejections
Hi Domenic,
Sorry to re-open an old thread; but this is important to me :).
Do you know if there’s been any progress on getting this behavior
standardized (or even
From: Boris Zbarsky [mailto:bzbar...@mit.edu]
We (Mozilla) support having something here.
Great! Thanks for your reply. And sorry for the lack of the specifics. We'll
work on nailing something down (spec-wise) as we implement, and of course far
ahead of any shipping. I'll reply when I get a
On Tue, May 19, 2015 at 2:07 PM, Domenic Denicola d...@domenic.me wrote:
An API being proposed on a mailing list such as this one?
The API is already proposed (see the rest of this thread).
Ah, sorry, I misunderstood your earlier email to mean that you were
intending to experiment with the API
From: Jonas Sicking [mailto:jo...@sicking.cc]
An API being proposed on a mailing list such as this one?
The API is already proposed (see the rest of this thread). The exact timing is
tricky to figure out without a working implementation to play with, compare to
real-world code, tweak, adjust,
From: whatwg [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Jonas Sicking
That sounds hard to provide feedback on...
What working mode would you prefer?
On 5/18/15 6:49 PM, Domenic Denicola wrote:
Ping. We're considering implementing this in Chrome and it would be helpful to
get a sense if other vendors support this.
We (Mozilla) support having something here. Not making the error event
even more complicated than it already is makes sense.
On Tue, May 19, 2015 at 1:57 PM, Domenic Denicola d...@domenic.me wrote:
It's hard to say what this you're talking about implementing in Chrome in
terms of the task-queueing behavior. Is that something you just haven't
decided on yet?
Yeah, I think this will be something that gets nailed
On Tue, May 19, 2015 at 2:04 PM, Domenic Denicola d...@domenic.me wrote:
From: whatwg [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Jonas
Sicking
That sounds hard to provide feedback on...
What working mode would you prefer?
An API being proposed on a mailing list such as this one?
On Tue, May 19, 2015 at 2:02 PM, Jonas Sicking jo...@sicking.cc wrote:
On Tue, May 19, 2015 at 1:57 PM, Domenic Denicola d...@domenic.me wrote:
It's hard to say what this you're talking about implementing in
Chrome in
terms of the task-queueing behavior. Is that something you just haven't
Antonov
Subject: Re: [whatwg] An API for unhandled promise rejections
An update on this: although the conversation somewhat fizzled here, in io.js
(Node.js fork) something very similar is landing and I'm trying to guide it
toward being reasonably compatible with browsers [1]. Additionally
: whatwg [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of
Domenic Denicola
Sent: Monday, February 9, 2015 20:45
To: WHATWG
Cc: Petka Antonov
Subject: Re: [whatwg] An API for unhandled promise rejections
An update on this: although the conversation somewhat fizzled here, in
io.js
The OP proposal.
-Original Message-
From: whatwg [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of
Elliott Sprehn
Sent: Monday, May 18, 2015 19:23
To: Domenic Denicola
Cc: WHATWG; Boris Zbarsky; Brian Terlson
Subject: Re: [whatwg] An API for unhandled promise rejections
What
An update on this: although the conversation somewhat fizzled here, in io.js
(Node.js fork) something very similar is landing and I'm trying to guide it
toward being reasonably compatible with browsers [1]. Additionally several
promise libraries have implemented similar hooks (see [2] and links
## Problem
A common desire in web programming is to log any uncaught exceptions back to
the server. The typical method for doing this is
window.onerror = (message, url, line, column, error) = {
// log `error` back to the server
};
When programming asynchronously with promises,
On 9/12/14, 2:34 PM, Domenic Denicola wrote:
Thank you for writing this up. This is definitely an area that needs
improvement.
As usual, if one or both of these events is missing listeners, nothing will
happen.
I'm not sure that's usual.
Specifically, an observable case that's worth
From: whatwg [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Boris Zbarsky
As usual, if one or both of these events is missing listeners, nothing will
happen.
I'm not sure that's usual.
I think I misspoke here. The events will still be fired! Anything else would be
insanity. I just
On 9/12/14, 3:19 PM, Domenic Denicola wrote:
If there is no listener for either when the promise would normally fire error, but then a
listener for rejectionhandled gets added before a .catch() call on the
promise, does the listener get called?
No.
That's not compatible with the events
From: Boris Zbarsky [mailto:bzbar...@mit.edu]
On 9/12/14, 3:19 PM, Domenic Denicola wrote:
If there is no listener for either when the promise would normally fire
error, but then a listener for rejectionhandled gets added before a
.catch() call on the promise, does the listener get called?
On 9/12/14, 3:45 PM, Domenic Denicola wrote:
var p = Promise.reject(new Error(boo));
setTimeout(() = {
window.onrejectionhandled = () = console.log(got here);
}, 100);
setTimeout(() = {
p.catch(() = {});
}, 200);
That's a good proxy for what I was envisioning...
In this case the
From: whatwg [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Boris Zbarsky
In this case the event would be fired
By the event do you mean the error event or the rejectionhandled event?
Ah, trick question! Because, see, I was confused when I wrote that, and myself
did not know!
but no
On 9/12/14, 4:07 PM, Domenic Denicola wrote:
To state what happens in that scenario more clearly:
- `error` is fired at time zero. Nobody is listening.
- `rejectionhandled` is fired at time 200 ms. Somebody is listening, and got
here is logged.
OK, good. We're on the same page!
-Boris
21 matches
Mail list logo
