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.
