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

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