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

On Wed, Oct 1, 2014 at 11:02 AM, Boris Zbarsky <> 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