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

On Wed, Oct 1, 2014 at 10:53 AM, Domenic Denicola <
domenic@domenicdenicola.com> wrote:

>
>
>
>
> > 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.
>

This is especially true if you wanted to try a series of calls (i.e.
supported media features). If the resolve function is only called on
success (i.e. supported and usable), then the rejection path can try the
next prefered option. If valid-call-but-not-supported is reported to the
resolve function and input-is-somehow-invalid-for-this-ua is reported as a
rejection, an application needs to call the try next logic in both branches.

Rejection also has the advantage of providing an exception, which can
provide information (reason and message) to differentiate between
potentially multiple causes. This is not possible when resolving with null.
Providing such information would likely make development and debugging
easier.

> >
> > ~TJ
>

Received on Wednesday, 1 October 2014 18:00:35 UTC