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

On Wed, Oct 1, 2014 at 11:52 AM, Jeffrey Yasskin <jyasskin@chromium.org> wrote:
> On Wed, Oct 1, 2014 at 6:06 AM, Anne van Kesteren <annevk@annevk.nl> wrote:
>> On Wed, Oct 1, 2014 at 2:56 PM, Peter Beverloo <beverloo@google.com> wrote:
>>> One argument I came across for overloading requestPermission is the
>>> following:
>>>     Promise.all([ Notification.requestPermission(),
>>> swRegistration.push.requestPermission() ]).then(...);
>>>
>>> Might be worth considering, it's relatively cheap to support and can be
>>> implemented without breaking backwards compatibility.
>>
>> One minor risk with also returning a promise is that exceptions for
>> incorrect invocation would no longer throw an exception, but instead
>> reject the promise.
>>
>> Otherwise I would never expect this promise to be rejected as the user
>> declining notifications is not exceptional.
>
> On a distributed system, a network error isn't unusual either, but it
> still makes sense to treat it as an exception because the
> application's main codepath can't continue executing. Similarly, if a
> permission the application expects isn't granted, the application has
> to skip the rest of its main codepath, so it makes sense to treat that
> as an exception too.

Precisely.

> If Tab wants to avoid try/catch blocks around most of his code, he can
> simply avoid using await for those promises, and transform their
> values with .catch(), but exceptions are really the same thing as
> «deal with rejections *later*, letting you execute a bunch of code on
> the success path and only at the end saying "Oh, did something along
> the line fail? Let me take care of that.".»

Yeah, you're right.  try/catch is just more annoying to use than a
.catch() at the end of a promise chain. ^_^

On Wed, Oct 1, 2014 at 11:34 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> I think we should develop Promises in a way that exploits their
> ergonomics properly, and then rethink async/await a bit to make it
> match those ergonomics, rather than fighting them.

For example, we could have *two* keywords for "awaiting" - one that
throws all rejections, and one that converts "non-fatal" errors
(tagged in the exception somehow) into fulfills for you automatically.
Or a method on Promise.prototype that does the same.  That way a
permission rejection can reject a promise usefully (letting you count
on the success path as meaning "I got permission"), and someone can
still, if they wish, handle no-permission in their normal code path
and leave errors for actual coding errors.

~TJ

Received on Wednesday, 1 October 2014 16:42:40 UTC