async/await improvements

[James Long]

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.

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.