W3C home > Mailing lists > Public > whatwg@whatwg.org > October 2014

Re: [whatwg] Notifications: making requestPermission() return a promise

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Wed, 1 Oct 2014 09:21:20 -0400
Message-ID: <CAAWBYDCHr7_ZvK6LO3N1BSURGZtKdW1hjmwSuNTxrzL8-x7wuA@mail.gmail.com>
To: Anne van Kesteren <annevk@annevk.nl>
Cc: WHATWG <whatwg@whatwg.org>, Jake Archibald <jaffathecake@gmail.com>, Jonas Sicking <jonas@sicking.cc>, Andrew Wilson <atwilson@google.com>, Peter Beverloo <beverloo@google.com>
On Wed, Oct 1, 2014 at 9:18 AM, Anne van Kesteren <annevk@annevk.nl> wrote:
> On Wed, Oct 1, 2014 at 3:14 PM, Tab Atkins Jr. <jackalmage@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 try/catch for anything other than invoking it
> with an argument such as "TEST", which is clearly wrong. That's why I
> don't think it's exceptional (e.g. warrants an exception/rejection).

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 of "onerror" events.

Without it, the promise algebra functions become far less useful, and
you have to type-test the fulfillment value to see if it's actually
the value you want, or some sort of proxy that communicates failure.

~TJ
Received on Wednesday, 1 October 2014 13:22:05 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:24 UTC