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

On 10/08/2014 08:58 PM, Tab Atkins Jr. wrote:
> 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.

One feedback to one API... that isn't really a strong argument.

"Fatal" errors indicating major issues in the program logic should be exposed to the
scripts asap, not hidden to Promises (and probably not handled at all)


-Olli


>
> ~TJ
>

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