> On Oct 1, 2014, at 18:22, Tab Atkins Jr. <jackalm...@gmail.com> wrote:
>
>> 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.
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