async/await improvements

[James Long]

On Wed, Nov 12, 2014 at 6:34 PM, Tab Atkins Jr. <jackalmage at gmail.com> wrote:
> On Wed, Nov 12, 2014 at 3:29 PM, James Long <longster at gmail.com> wrote:
>> On Wed, Nov 12, 2014 at 6:18 PM, Tab Atkins Jr. <jackalmage at gmail.com> wrote:
>>> No, you're misunderstanding me, or the way that async stuff works.
>>>
>>> Calling an async function returns immediately.  The called function
>>> doesn't actually run until a later turn.  If it throws, there's *no
>>> way*, even theoretically, to throw that error at the call-site,
>>> because the program counter is already well past that point.
>>>
>>> If you want the call-site to throw, then you need the callsite itself
>>> to be in an async function, and you need to use the "await"
>>> expression, which pauses execution of the caller until the callee's
>>> returned promise settles.  At that point you can throw the rejection
>>> value, or return the fulfillment value.
>>
>> Trust me in that I've done a lot of async coding and I understand well
>> how it works. The thing I may not understand fully is the current
>> async/await spec.
>>
>> The difference is what happens with `await`, does it throw or does it
>> automatically put the error on the promise returned from the async
>> function. I'm essentially saying it should throw by default and you
>> need to manually forward it. That's all. It doesn't really break
>> anything.
>
> Something's still going wrong in your understanding here.  "await"
> *receives* a promise.  It doesn't return one.  It either returns the
> fulfillment value or throws the rejection value.  The question you're
> asking doesn't make sense.
>
> ~TJ

`await` is *always* inside an `async` function so there's always a
promise created for that function which is waiting for it to be done
executing. That's the one I'm talking about.