- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Wed, 1 Oct 2014 12:41:53 -0400
- To: Jeffrey Yasskin <jyasskin@chromium.org>
- Cc: 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 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