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

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

From: Anne van Kesteren <annevk@annevk.nl>
Date: Wed, 1 Oct 2014 15:34:38 +0200
Message-ID: <CADnb78hWeFMTPYydEbJrHBtRbSNp2=A3MctJNL0V_SMSFBmPgA@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
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 3:21 PM, Tab Atkins Jr. <jackalmage@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 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.

Once we have async/await syntax the synchronous version is what you
get. I would not want try/catch for requestPermission() there. As far
as I know promises are just like functions in that regard, you only
want to reject/throw if you want to force try/catch on the user.


-- 
https://annevankesteren.nl/
Received on Wednesday, 1 October 2014 13:35:03 UTC

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