Tab Atkins Jr.
jackalmage at gmail.com
Wed Nov 12 14:56:10 PST 2014
On Wed, Nov 12, 2014 at 2:49 PM, Jeff Morrison <lbljeffmo at gmail.com> 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 gmail.com>
>>> Crazy, half-baked idea: Move the "forwards" vs "throws/logs" distinction
>>> the callsite (in sync contexts only?) rather than the definition context
>>> 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.
More information about the es-discuss