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

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

From: Tobie Langel <tobie.langel@gmail.com>
Date: Wed, 1 Oct 2014 19:02:37 +0200
Message-ID: <CAMK=o4cXx-ihjt7WX287SpTB29-U9B0E_oe2gTJ0VJaLOfFKhA@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: Andrew Wilson <atwilson@google.com>, WHATWG <whatwg@whatwg.org>, Jake Archibald <jaffathecake@gmail.com>, Peter Beverloo <beverloo@google.com>, Jonas Sicking <jonas@sicking.cc>
On Wed, Oct 1, 2014 at 5:59 PM, Tab Atkins Jr. <jackalmage@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 expect quite contrary to most people's
> expectations.
>

I'm with Domenic, here. We had these conversations for the Service Worker
Cache's .match() method and dropped promise rejection in favor of resolving
with null when a relevant Response object couldn't be found in the cache.
Rejecting the promise was left for truly exceptional cases, such a data
corruption issues.

I agree with you that the code branching provided by the resolve/reject
pair looks appealing at first, but it's terrible once awaits comes in the
picture.
Received on Wednesday, 1 October 2014 17:03:04 UTC

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