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

On Wed, Oct 8, 2014 at 10:54 AM, Olli Pettay <olli@pettay.fi> wrote:
> 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.

As was stated in a recent bug thread you were participating in, we got
feedback from authors using IDB that they actually quite disliked
having to handle *some* errors via try/catch and *other* errors via
error callbacks, and would have preferred they all go through the
error callback.

~TJ

Received on Wednesday, 8 October 2014 17:59:07 UTC