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 <longs...@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 <zenpars...@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.arvids...@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@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
