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

On 10/08/2014 08:03 PM, Tab Atkins Jr. wrote:
> 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.
(off topic to Notifications)
That is a main point of exceptions. If your code is horribly broken,
like wrong params passed to some method, execution should stop asap.
The fact that Promise returning functions don't throw immediately is a crazy setup
since one may just ignore and not notice at all the rather bad error in the
program logic.


> 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:54:50 UTC