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

> On Oct 1, 2014, at 18:22, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> 
>> On Wed, Oct 1, 2014 at 1:02 PM, Tobie Langel <tobie.langel@gmail.com> wrote:
>>> On Wed, Oct 1, 2014 at 5:59 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>>> I've never heard this opinion explicitly expressed, and it has never
>>> shown up in any API reviews of promise-using specs.  It's directly
>>> contrary to the way that existing non-promise async APIs are
>>> constructed, and I expect quite contrary to most people's
>>> expectations.
>> 
>> I'm with Domenic, here. We had these conversations for the Service Worker
>> Cache's .match() method and dropped promise rejection in favor of resolving
>> with null when a relevant Response object couldn't be found in the cache.
>> Rejecting the promise was left for truly exceptional cases, such a data
>> corruption issues.
>> 
>> I agree with you that the code branching provided by the resolve/reject pair
>> looks appealing at first, but it's terrible once awaits comes in the
>> picture.
> 
> Wow, that's kinda terrible.  The operation literally failed; there is
> no way in which it could be said to have succeeded, and you absolutely
> want to run different code paths based on whether it succeeded or
> failed.  Instead, you are forced to either run your failure-path code
> in the fulfill callback alongside the success-path code, or do what I
> said upthread and add a `if(arg == null) throw` line to the top of
> your fulfill callback so you can treat the fulfill callbacks as always
> succeeding.
> 
> Note that Python, for example, throws errors on dict keys not being
> found (unless you specifically tell it a sentinel value to return
> instead).  Do you think that's terrible?
> 
> This sort of behavior makes promise rejection essentially worthless.

They are as "worthless" as exceptions.

> You can't base anything off of whether a promise fulfilled or not,
> because it'll only fail for weird exceptional cases; most of your
> "failures" (cases where the thing you were asking for couldn't be
> done) are instead mixed into your fulfill channel.
> 
> ~TJ

Received on Wednesday, 1 October 2014 17:54:08 UTC