- From: Tobie Langel <tobie.langel@gmail.com>
- Date: Wed, 1 Oct 2014 19:02:37 +0200
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- Cc: Andrew Wilson <atwilson@google.com>, WHATWG <whatwg@whatwg.org>, Jake Archibald <jaffathecake@gmail.com>, Peter Beverloo <beverloo@google.com>, Jonas Sicking <jonas@sicking.cc>
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.
Received on Wednesday, 1 October 2014 17:03:04 UTC