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. 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