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

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

From: David Dorwin <ddorwin@chromium.org>
Date: Wed, 1 Oct 2014 11:30:09 -0700
Message-ID: <CAHD2rsgrivYiV7qnk62GshEPYX50q=K0h6e_ihnA+rQRJ9ZFeQ@mail.gmail.com>
To: Boris Zbarsky <bzbarsky@mit.edu>
Cc: whatwg@lists.whatwg.org
On Wed, Oct 1, 2014 at 11:02 AM, Boris Zbarsky <bzbarsky@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 possible when resolving with
>> null.
>> Providing such information would likely make development and debugging
>> easier.
> If you were designing a sync API, would not the same arguments apply? So
> you'd want to throw different kinds of exceptions to indicate "not
> supported"?

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
different exception names.)

However, it sounds like something not being supported by a UA would not be
"exceptional," so an exception should not be thrown in this case. (This is
no less expected than "the user
declining notifications".) I guess the synchronous API would return null.
That seems odd since an exception has historically been thrown in such

> -Boris
Received on Wednesday, 1 October 2014 18:30:57 UTC

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