- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Wed, 8 Oct 2014 08:57:14 -0700
- To: Anne van Kesteren <annevk@annevk.nl>
- Cc: Andrew Wilson <atwilson@google.com>, WHATWG List <whatwg@whatwg.org>, Jake Archibald <jaffathecake@gmail.com>, Peter Beverloo <beverloo@google.com>, Jonas Sicking <jonas@sicking.cc>
On Wed, Oct 8, 2014 at 1:07 AM, Anne van Kesteren <annevk@annevk.nl> wrote: > On Wed, Oct 8, 2014 at 9:51 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote: >> The question is whether it's not natural to assume that *if the promise >> fulfills*, that means they got permission. This allows them to do things >> like using Promise.all() to join multiple permission requests together and >> get a nice combined promise that fulfills when everything succeeds, or write >> a nice straight success path that assumes permission, and then handle any >> errors, including denied permission, at the end, rather than interleaving >> error-handling logic into the middle of your code. > > Okay, given that question I agree it's natural to assume that this > happens when it resolves. However, a user declining permission is not > exceptional behavior and therefore should not cause an exception. In > synchronous code you would not want to write try/catch here. An error or failure event *is* an asynchronous exception. It's a completely different code path from the success event that you can handle separately, while writing code for the success path that assumes you got the things you needed. Do you think that every single instance of error events we've used in the past was a mistake, and we should have instead just had a "complete" event that both success and failure used? For example, should <img>.onload fire when the image fails to load? This is *exactly* analogous to a permission request succeeding or failing, as far as I can tell, but for the equivalent image situation, I believe you're okay with a failed load rejecting the .ready promise (or whatever we're planning to name it). There are certainly cases where only actual exceptions would cause rejection - Domenic's example of a "userAllowsNotifications()" function is clearly going to fulfill with a boolean, and only reject if you fuck something up. But requesting a permission is an operation that can fail, and failure is exceptional, and we've reflected this precise distinction in tons of past APIs via an error event. Why was every single past API that used this pattern mistaken? Again, if this means that the current design for "await" becomes less convenient, *we can fix await to work better*. It's not set in stone, it's not developed yet. This is a thing we can change. But let's not twist our necks around and force promise APIs into an unnatural and inconvenient shape just because a naive translation to sync code produces errors and people find try/catch annoying or distasteful. ~TJ
Received on Wednesday, 8 October 2014 15:58:00 UTC