On Wed, Oct 1, 2014 at 1:02 PM, Tobie Langel <tobie.lan...@gmail.com> wrote:
> On Wed, Oct 1, 2014 at 5:59 PM, Tab Atkins Jr. <jackalm...@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.
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

Reply via email to