async/await improvements

[Jeff Morrison]

On 11/12/14, 9:57 AM, James Long wrote:
> 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.
`await` is currently a reserved identifier in ES6 modules to leave the 
option of doing toplevel awaits in a module body in the future.
This is interesting, because it would pave the way for a toplevel-rooted 
async stack as you describe here...
>
> Can anyone with knowledge of how current JS engines work confirm that?
>
> On Wed, Nov 12, 2014 at 9:49 AM, James Long <longster at gmail.com> wrote:
>> Not sure of the best way to reply to both emails, guess I'll just
>> inline both here:
>>
>> On Wed, Nov 12, 2014 at 8:38 AM, Kevin Smith <zenparsing at gmail.com> wrote:
>>> Hi James,
>>>
>>> As you point out, exception swallowing is a problem for promises in general.
>>> The best way to approach the issue as it applies to async/await is to just
>>> solve it for promises.  The current direction JS engines are taking is to
>>> log unhandled rejections in one way or another.  I would keep an eye on
>>> those developments.
>> Yes, I have (I work on the Firefox devtools). The best we can do (as
>> far as I know) is log an error when a promise is GC-ed with an
>> unhandled error, which isn't great in my opinion. It doesn't help at
>> all for production (sure, "you aren't using promises correctly" and
>> all that, but not all programmers are perfect). Also makes it harder
>> for tests, because I don't think we've standardized an
>> onUncaughtPromiseException, and if we have, it's GC-sensitive. Lastly
>> just waiting a few seconds to see your error sucks (who knows when the
>> GC happens, maybe you kept a reference and it never does). You also
>> lose "pause on uncaught exception" since the call context gone.
>>
>> I don't want fall into a promise war here, but I'm just suggesting an
>> idea for async/await to avoid all of that, though it does change the
>> error handling semantics.
>>
>> On Wed, Nov 12, 2014 at 9:29 AM, Erik Arvidsson
>> <erik.arvidsson at gmail.com> wrote:
>>> I don't understand how that would work? The exception might not happen in
>>> the current turn.
>>>
>>> async function foo() {
>>>    await sleep(1000);
>>>    throw new Error();
>>> }
>>>
>>> Maybe all you were saying is that, if there is an exception before the first
>>> await then throw instead of reject?
>>>
>> I don't see why it wouldn't work. An async function returns a deferred
>> object, which other functions can use `await` to wait on. Whenever the
>> error happens, put it on the deferred object (if using `async^`) and
>> whenever another `async` function tries to access it with `await` it
>> will throw the error.
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss