async/await improvements

Kevin Smith zenparsing at
Wed Nov 12 07:29:48 PST 2014

> Actually, it is possible we can do this without any extra syntax at
> all (no `await^`). If we restrict async functions to only be able to
> be called by other async functions, the engine should be able to keep
> track of the async stack and throw errors appropriately up the chain,
> and know when it hits a top-level async function and throw the error
> for real automatically.

Hmm...  One of the nice properties of the current design is that the caller
doesn't need to know whether the called function is "async" or not.  All it
needs to know is whether the function returns a promise.  With this setup
we'd lose that encapsulation.

Again, this is a generic issue for promises:  a good solution there will
"fix" everything.

My preferred solution to this problem:  modify host-to-user "dispatchers"
so that if user code returns a rejected promise to the host, an error is
reported.  So for instance, if user code returns a rejected promise from a
DOM element event handler, the browser would log the error and call
`window.onerror`.  With async functions, this would work almost

    element.addEventListener("click", async event => {
        throw new Error("boom");

The host would pick up the rejection returned from the handler and report
the error.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list