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-boun...@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

Reply via email to