- From: Jeffrey Yasskin <jyasskin@chromium.org>
- Date: Wed, 1 Oct 2014 08:52:53 -0700
- To: Anne van Kesteren <annevk@annevk.nl>
- Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, Andrew Wilson <atwilson@google.com>, WHATWG <whatwg@whatwg.org>, Jake Archibald <jaffathecake@gmail.com>, Peter Beverloo <beverloo@google.com>, Jonas Sicking <jonas@sicking.cc>
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. 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.".»
Received on Wednesday, 1 October 2014 15:53:39 UTC