On Tue, Oct 7, 2014 at 8:33 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Sun, Oct 5, 2014 at 7:41 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Thu, Oct 2, 2014 at 10:13 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
So we should make a choice, as to whether we want developers
On Oct 7, 2014 11:32 PM, Anne van Kesteren ann...@annevk.nl wrote:
On Tue, Oct 7, 2014 at 8:33 PM, Tab Atkins Jr. jackalm...@gmail.com
wrote:
On Sun, Oct 5, 2014 at 7:41 AM, Anne van Kesteren ann...@annevk.nl
wrote:
On Thu, Oct 2, 2014 at 10:13 PM, Domenic Denicola
On Wed, Oct 8, 2014 at 9:51 AM, Tab Atkins Jr. jackalm...@gmail.com wrote:
The question is whether it's not natural to assume that *if the promise
fulfills*, that means they got permission. This allows them to do things
like using Promise.all() to join multiple permission requests together and
On Wed, Oct 8, 2014 at 9:51 AM, Tab Atkins Jr. jackalm...@gmail.com wrote:
The question is whether it's not natural to assume that *if the promise
fulfills*, that means they got permission. This allows them to do things
like using Promise.all() to join multiple permission requests together and
On Wed, Oct 8, 2014 at 1:07 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Wed, Oct 8, 2014 at 9:51 AM, Tab Atkins Jr. jackalm...@gmail.com wrote:
The question is whether it's not natural to assume that *if the promise
fulfills*, that means they got permission. This allows them to do things
On Wed, Oct 8, 2014 at 1:31 AM, Tobie Langel tobie.lan...@gmail.com wrote:
On Wed, Oct 8, 2014 at 9:51 AM, Tab Atkins Jr. jackalm...@gmail.com wrote:
The question is whether it's not natural to assume that *if the promise
fulfills*, that means they got permission. This allows them to do things
On Wed, Oct 8, 2014 at 5:59 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Wed, Oct 8, 2014 at 1:31 AM, Tobie Langel tobie.lan...@gmail.com
wrote:
On Wed, Oct 8, 2014 at 9:51 AM, Tab Atkins Jr. jackalm...@gmail.com
wrote:
The question is whether it's not natural to assume that *if the
From: Tab Atkins Jr. [mailto:jackalm...@gmail.com]
Again, if this means that the current design for await becomes less
convenient, *we can fix await to work better*. It's not set in stone, it's
not developed yet. This is a thing we can change.
To be clear, this will not be happening.
On Wed, Oct 8, 2014 at 6:07 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
What I find interesting here is the claim that people find try/catch annoying
or distasteful.
I don't think you should need try/catch for a common failure case.
That is all. So yes, agreed with Tobie et al.
From: annevankeste...@gmail.com [mailto:annevankeste...@gmail.com] On Behalf Of
Anne van Kesteren
I don't think you should need try/catch for a common failure case.
Ah, this is the crux of our minor-disagreement, I think.
IMO using try/catch for a common failure case is fine, *as long as you
On Wed, Oct 8, 2014 at 9:16 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Wed, Oct 8, 2014 at 6:07 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
What I find interesting here is the claim that people find try/catch
annoying or distasteful.
I don't think you should need try/catch
On Wed, Oct 8, 2014 at 7:03 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
You keep ignoring the past turns out we like using async errors for
'soft failures' of this kind, and have done it lots of times, and
nobody seems to complain argument.
A user saying no to notifications is not an error.
On Wed, Oct 8, 2014 at 10:39 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Wed, Oct 8, 2014 at 7:03 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
You keep ignoring the past turns out we like using async errors for
'soft failures' of this kind, and have done it lots of times, and
nobody
On 10/08/2014 08:03 PM, Tab Atkins Jr. wrote:
On Wed, Oct 8, 2014 at 9:16 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Wed, Oct 8, 2014 at 6:07 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
What I find interesting here is the claim that people find try/catch annoying
or
On Wed, Oct 8, 2014 at 9:16 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Wed, Oct 8, 2014 at 6:07 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
What I find interesting here is the claim that people find try/catch
annoying or distasteful.
I don't think you should need try/catch
On Wed, Oct 8, 2014 at 10:39 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Wed, Oct 8, 2014 at 7:03 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
You keep ignoring the past turns out we like using async errors for
'soft failures' of this kind, and have done it lots of times, and
nobody
On Sun, Oct 5, 2014 at 7:41 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Thu, Oct 2, 2014 at 10:13 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
So we should make a choice, as to whether we want developers to assume they
will always get permission (in which case it should reject
On Thu, Oct 2, 2014 at 10:13 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
So we should make a choice, as to whether we want developers to assume they
will always get permission (in which case it should reject upon permission
not being granted), or whether we want developers to ask
On Oct 5, 2014 7:41 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Thu, Oct 2, 2014 at 10:13 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
So we should make a choice, as to whether we want developers to assume
they will always get permission (in which case it should reject upon
My previous replies to this thread have been about more general issues
regarding promises and exceptions where I felt the need to jump in. Now, about
the actual specific case at hand...
From: whatwg [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Anne van
Kesteren
Otherwise I would
On Wed, Oct 1, 2014 at 2:56 PM, Peter Beverloo bever...@google.com wrote:
One argument I came across for overloading requestPermission is the
following:
Promise.all([ Notification.requestPermission(),
swRegistration.push.requestPermission() ]).then(...);
Might be worth considering, it's
On Wed, Oct 1, 2014 at 9:06 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Wed, Oct 1, 2014 at 2:56 PM, Peter Beverloo bever...@google.com wrote:
One argument I came across for overloading requestPermission is the
following:
Promise.all([ Notification.requestPermission(),
On Wed, Oct 1, 2014 at 3:14 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
Wait, what? Anytime you request something, not getting it is
exceptional. Not sure how you can make an argument otherwise.
I would not expect a synchronous version of this method (were it to
exist) to have to use
On Wed, Oct 1, 2014 at 9:18 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Wed, Oct 1, 2014 at 3:14 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
Wait, what? Anytime you request something, not getting it is
exceptional. Not sure how you can make an argument otherwise.
I would not expect
On 01/10/14 14:21, Tab Atkins Jr. wrote:
On Wed, Oct 1, 2014 at 9:18 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Wed, Oct 1, 2014 at 3:14 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
Wait, what? Anytime you request something, not getting it is
exceptional. Not sure how you can make an
On Wed, Oct 1, 2014 at 3:21 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
And I wouldn't expect someone loading a FontFace synchronously to use
try/catch to deal with loading errors, either, because that's super
obnoxious. Failure, though, is a standard rejection reason - it maps
to the use
On Wed, Oct 1, 2014 at 9:34 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Wed, Oct 1, 2014 at 3:21 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
And I wouldn't expect someone loading a FontFace synchronously to use
try/catch to deal with loading errors, either, because that's super
From: whatwg [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Tab Atkins
Jr.
This is actually kinda terrible. Promises make it *really easy* to deal with
rejections *later*, letting you execute a bunch of code on the success path
and only at the end saying Oh, did something along the
On Wed, Oct 1, 2014 at 6:06 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Wed, Oct 1, 2014 at 2:56 PM, Peter Beverloo bever...@google.com wrote:
One argument I came across for overloading requestPermission is the
following:
Promise.all([ Notification.requestPermission(),
On Wed, Oct 1, 2014 at 11:44 AM, Domenic Denicola
dome...@domenicdenicola.com wrote:
From: whatwg [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Tab Atkins
Jr.
This is actually kinda terrible. Promises make it *really easy* to deal
with rejections *later*, letting you execute a
On Wed, Oct 1, 2014 at 11:52 AM, Jeffrey Yasskin jyass...@chromium.org wrote:
On Wed, Oct 1, 2014 at 6:06 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Wed, Oct 1, 2014 at 2:56 PM, Peter Beverloo bever...@google.com wrote:
One argument I came across for overloading requestPermission is the
On Wed, Oct 1, 2014 at 5:59 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
I've never heard this opinion explicitly expressed, and it has never
shown up in any API reviews of promise-using specs. It's directly
contrary to the way that existing non-promise async APIs are
constructed, and I
On Wed, Oct 1, 2014 at 1:02 PM, Tobie Langel tobie.lan...@gmail.com wrote:
On Wed, Oct 1, 2014 at 5:59 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
I've never heard this opinion explicitly expressed, and it has never
shown up in any API reviews of promise-using specs. It's directly
contrary
On Wed, Oct 1, 2014 at 7:22 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
Note that Python, for example, throws errors on dict keys not being
found (unless you specifically tell it a sentinel value to return
instead). Do you think that's terrible?
Sure. But JS doesn't.
On Oct 1, 2014, at 16:59, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Wed, Oct 1, 2014 at 11:44 AM, Domenic Denicola
dome...@domenicdenicola.com wrote:
From: whatwg [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Tab
Atkins Jr.
This is actually kinda terrible. Promises make
On Oct 1, 2014, at 18:22, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Wed, Oct 1, 2014 at 1:02 PM, Tobie Langel tobie.lan...@gmail.com wrote:
On Wed, Oct 1, 2014 at 5:59 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
I've never heard this opinion explicitly expressed, and it has never
On Wed, Oct 1, 2014 at 10:53 AM, Domenic Denicola
dome...@domenicdenicola.com wrote:
On Oct 1, 2014, at 18:22, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Wed, Oct 1, 2014 at 1:02 PM, Tobie Langel tobie.lan...@gmail.com
wrote:
On Wed, Oct 1, 2014 at 5:59 PM, Tab Atkins Jr.
On 10/1/14, 1:59 PM, David Dorwin wrote:
Rejection also has the advantage of providing an exception, which can
provide information (reason and message) to differentiate between
potentially multiple causes. This is not possible when resolving with null.
Providing such information would likely
On Wed, Oct 1, 2014 at 11:02 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 10/1/14, 1:59 PM, David Dorwin wrote:
Rejection also has the advantage of providing an exception, which can
provide information (reason and message) to differentiate between
potentially multiple causes. This is not
On Wed, Oct 1, 2014 at 8:30 PM, David Dorwin ddor...@chromium.org wrote:
I would specify that DOMException with the name NotSupportedError be
thrown. User agent implementations could provide more information in the
message. (There might be other non-exceptional failures that would use
On Wed, Oct 1, 2014 at 11:43 PM, Anne van Kesteren ann...@annevk.nl wrote:
Given async/await the only reasonable thing to do seems to me
to model them after functions and only use rejection for something
exceptional, but with the level of disagreement this has created in
several different
On Wed, 1 Oct 2014, Domenic Denicola wrote:
This sort of behavior makes promise rejection essentially worthless.
They are as worthless as exceptions.
Some exceptions _are_ worthless, as witnessed by the fact that nobody
ever tries to catch them. For example, TypeError.
This is why I've
42 matches
Mail list logo
