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

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

From: Jonas Sicking <jonas@sicking.cc>
Date: Wed, 8 Oct 2014 11:08:30 -0700
Message-ID: <CA+c2ei_ChUG3vN_TGhjFL+p2beLQR+Ybap4ZH4J0vootgQCtzg@mail.gmail.com>
To: Anne van Kesteren <annevk@annevk.nl>
Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, Andrew Wilson <atwilson@google.com>, WHATWG List <whatwg@whatwg.org>, Jake Archibald <jaffathecake@gmail.com>, Peter Beverloo <beverloo@google.com>
On Wed, Oct 8, 2014 at 9:16 AM, Anne van Kesteren <annevk@annevk.nl> wrote:
> On Wed, Oct 8, 2014 at 6:07 PM, Domenic Denicola
> <domenic@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.

Another thing to keep in mind here is that it's pretty easy to convert
between either of these behaviors. It's just a matter of either doing

requestPermission().then((r) => { if (!r) throw Error(...) })

requestPermission().then(() => true, () => false)

Or, using the await syntax

async function() {
  if (!await requestPermission())
    throw Error(...);

async function() {
  hasPermission = true;
  try {
    await requestPermission();
  catch {
    hasPermission = false;

So I think a more important question here is what behavior would an
author expect. I think one of the points Dominic tried to make earlier
is that the name is important for setting that expectation and help
authors understand how the function behaves. Sadly the name that we're
stuck with doesn't really provide much guidance either way.

But I think to some extent it's indicating that we're bikeshedding here.

/ Jonas
Received on Wednesday, 8 October 2014 18:09:26 UTC

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