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

My previous replies to this thread have been about more general issues regarding promises and exceptions where I felt the need to jump in. Now, about the actual specific case at hand...

From: whatwg [mailto:whatwg-bounces@lists.whatwg.org] On Behalf Of Anne van Kesteren

> Otherwise I would never expect this promise to be rejected as the user declining notifications is not exceptional.

I think this is a judgment call. The definition of "exceptional" is always a bit tricky. Really it comes down to, "should the developer always handle this case or not?"

For example, failures like a file being unreadable can be considered exceptional, since often a developer doesn't want to handle such failures, but instead wants to put a big try {} block around a bunch of logic, and if any of it failed, say "something went wrong".

I also maintain that this is partially in how the function is named. For example, if your function is called `writeToFile()` or `acquireNotificationPermission()`, it can be considered exceptional for it to fail.

To illustrate this, let's work in a world with only-sync calls, since that reduces peoples confusion about this new promises concept and what's appropriate there. The developer will likely include such calls in a sequence of operations, one after the other, and expect none of them to fail:

```js
acquireNotificationPermission();
var data = prepareNotificationData();
showNotification(data);
removeFromNotificationQueue(data);
```

in this example, any failures in any of these steps will bubble up to window.onerror, and get sent to telemetry. That seems OK, and in-line with the intent of the code.

Whereas, if the function is named `userAllowsNotifications()`, it is much clearer that you would do

```js
var canNotify = userAllowsNotifications();
if (canNotify) {
  var data = prepareNotificationData();
  showNotification(data);
  removeFromNotificationQueue(data);
}
```

So to me, the question comes down to: do we want to design our APIs around the model of `acquireNotificationPermission()`, where the developer codes as if getting permission is an expected normal thing? Or do we want to code them around the model of `userAllowsNotifications()`, where the developer is explicitly asking a question?

To answer some contentions that the latter style would force duplicate error handling with promises: it would not. Very similar to sync code, you would write

```js
userAllowsNotifications().then(canNotify => {
  if (canNotify) {
    var data = prepareNotificationData();
    showNotification(data);
    removeFromNotificationQueue(data);
  }
});
```

and any other errors (e.g. programming errors, like if someone had typo'd prepareNotificationData()) would flow up to the developer tools, and eventually to window.onerror or similar once we get that specced [1]. You would not write an explicit `.catch(...)` to handle such failures.

(And yes, only Firefox's developer tools correctly show such errors; Chrome is embarrassingly behind in that regard.)

---

Bringing this back to requestPermission() and notifications: honestly, the name doesn't help me much in deciding which programming model we want. It could go either way.

So we should make a choice, as to whether we want developers to assume they will always get permission (in which case it should reject upon permission not being granted), or whether we want developers to ask the API whether they were granted permission (in which case it should give back a boolean fulfillment value or similar).


[1]: http://lists.w3.org/Archives/Public/public-whatwg-archive/2014Sep/0024.html

Received on Thursday, 2 October 2014 20:14:09 UTC