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

On Wed, Oct 8, 2014 at 9:16 AM, Anne van Kesteren <annevk@annevk.nl> wrote:
> On Wed, Oct 8, 2014 at 6:07 PM, Domenic Denicola
> <domenic@domenicdenicola.com> wrote:
>> What I find interesting here is the claim that people find try/catch annoying or distasteful.
>
> I don't think you should need try/catch for a common failure case.
> That is all. So yes, agreed with Tobie et al.

You keep arguing from the future "rejections become errors" position.
You keep ignoring the past "turns out we like using async errors for
'soft failures' of this kind, and have done it lots of times, and
nobody seems to complain" argument.

Do you dislike img.onerror firing when the image doesn't load?  (And
same for all the other resource-loading elements.)  Do you dislike
geolocator.getCurrentPosition calling the failure callback when the
user refuses permission?  Do you dislike IDB firing error events on
several types of failure, ranging from exceptional to mundane?

If there are any of these you do *not* dislike, why?  And why doesn't
the logic from those apply to this situation?

On Wed, Oct 8, 2014 at 9:18 AM, Domenic Denicola
<domenic@domenicdenicola.com> wrote:
> Ah, this is the crux of our minor-disagreement, I think.
>
> IMO using try/catch for a common failure case is fine, *as long as you want that failure to bubble up the call stack*. E.g., if you want to handle it at a higher level along with other failures, or if you want to ignore the possibility of failure except in how errors get sent to `window.onerror`.
>
> Now, I think we're likely in *agreement* that you don't actually want to do this for requestPermission---you should handle it as soon as possible. But our reasoning is different, and now I understand why.

The problem here is that try/catch *is* distasteful, while promise
rejection isn't, and it's all ergonomics.

* try/catch produces rightward drift, promise reject handlers do not
* errors bubble up indefinitely until they're caught, breaking all of
your code.  Rejections bubble down a single promise chain, and can be
ignored if you're done with a chain without anything bad happening.
(And some Promise algebra functions like .race() can swallow a
rejection without rejecting the chain, if another one fulfilled first,
so you don't even have to think about the rejection.)
* We've been taught not to use exceptions for control flow, but we
have the Promise algebra to help us do control flow based on promises
fulfilling/rejecting (and more mature Promise libraries tend to grow
more algebra over time).

Errors suck, but they're the way we do rejections syncly.  I hate that
we're compromising on the built-in ergonomics of Promises in order to
avoid triggering the worse ergonomics of errors in the future. :(

~TJ

Received on Wednesday, 8 October 2014 17:04:12 UTC