async/await improvements

[James Long]

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.

The only thing you can ever get with async is a single stack frame
(unless you are logging long stack traces), but with that single stack
frame you could still do "pause on uncaught exception" and see the
local state for at least that.

When using async/await, how do you tell an async function that it's
the top-level one and it should throw all errors (the equivalent to
.done())? I don't see that anywhere.