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.

Reply via email to