- From: Domenic Denicola <domenic@domenicdenicola.com>
- Date: Wed, 1 Oct 2014 17:53:41 +0000
- To: Tab Atkins Jr. <jackalmage@gmail.com>
- Cc: Andrew Wilson <atwilson@google.com>, WHATWG <whatwg@whatwg.org>, Tobie Langel <tobie.langel@gmail.com>, Jake Archibald <jaffathecake@gmail.com>, Peter Beverloo <beverloo@google.com>, Jonas Sicking <jonas@sicking.cc>
> On Oct 1, 2014, at 18:22, Tab Atkins Jr. <jackalmage@gmail.com> wrote: > >> On Wed, Oct 1, 2014 at 1:02 PM, Tobie Langel <tobie.langel@gmail.com> wrote: >>> 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. > > 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
Received on Wednesday, 1 October 2014 17:54:08 UTC