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

On Wed, Oct 1, 2014 at 8:30 PM, David Dorwin <ddorwin@chromium.org> wrote:
> 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.)

We typically use non-throwing mechanism for unsupported features. E.g.
properties that accept enumerations that when set to an unknown
enumeration don't change. From experience, this tends to break pages
less in user agents not offering certain features. This is also why
XMLHttpRequest evolved to throw less exceptions over time.

However, that seems like a bit of a digression from the main issue
here. Which is whether promises-returning methods should be modeled
after functions (return/throw) or have some kind of alternative
design. Given async/await the only reasonable thing to do seems to me
to model them after functions and only use rejection for something
exceptional, but with the level of disagreement this has created in
several different standards group thus far, I'm not hopeful initial
promise APIs will be consistent in this.


-- 
https://annevankesteren.nl/

Received on Wednesday, 1 October 2014 21:44:21 UTC