async/await improvements

Jeff Morrison lbljeffmo at
Wed Nov 12 16:57:43 PST 2014

Note that in my "crazy idea" I didn't say rethrow -- I carefully called it out as more of a "log" than a throw.

Sent from my iPhone

> On Nov 12, 2014, at 5:56 PM, Tab Atkins Jr. <jackalmage at> wrote:
>> On Wed, Nov 12, 2014 at 2:49 PM, Jeff Morrison <lbljeffmo at> wrote:
>>> On 11/12/14, 5:23 PM, Tab Atkins Jr. wrote:
>>> On Wed, Nov 12, 2014 at 2:15 PM, Jeff Morrison <lbljeffmo at>
>>> wrote:
>>>> Crazy, half-baked idea: Move the "forwards" vs "throws/logs" distinction
>>>> to
>>>> the callsite (in sync contexts only?) rather than the definition context
>>>> as
>>>> was described at the beginning of this thread.
>>> This is already the case.  If you want the promise (which "forwards"
>>> errors), just call the async function normally.  If you want errors to
>>> throw through you like a sync function would, use the "await"
>>> expression (which requires you to be async as well).
>> Indeed you could convert the entire signature of your calling function (and
>> incur all the effects on the downstream call sites in doing so), but I was
>> aiming for a less intrusive escape hatch.
>> Additionally, if you're ever operating at a toplevel somewhere, you don't
>> really have this option.
> It's impossible to rethrow errors without use of "await" - the error
> may happen in a different turn entirely than the function call.  You
> *must* convert your calling function into an async one, so that it can
> do the "freeze and wait for the promise to resolve" thing, which means
> that it needs to return a promise for itself as well.
> ~TJ
> _______________________________________________
> es-discuss mailing list
> es-discuss at

More information about the es-discuss mailing list