When mixing callback logic with async functions, it's up to the programmer
to choose the callback semantics that they want.
Forcing execution of the async function into a future task prohibits logic
that requires immediate invocation of a callback, whereas the existing
semantics allow for both immediate and future invocation. At any rate, I
assume this ship has sailed. This is a pretty foundational change to make
in a Stage 4 proposal.
On Tue, Nov 29, 2016 at 11:15 AM, Paolo Amadini <paolo.02....@amadzone.org>
wrote:
> As I understand it, as currently specified, the first part of an async
> function, before the first await statement, is executed synchronously.
>
> This is subject to subtle bugs when used with callbacks, which may be
> common with DOM event handlers. Take the following code example:
>
> ```js
> let someCondition = false;
>
> async function onClick(event) {
> if (someCondition) {
> await Promise.resolve(); // Or any other async function.
> }
> event.stopPropagation();
> }
>
> let called = false;
> onClick({ stopPropagation: () => called = true }).catch(console.error);
> console.log("Called:", called);
> ```
>
> The callback is called synchronously or not based on someCondition.
>
> The behavior would be more consistent if the first part of the function
> was scheduled at the next microtask, in other words it would be like
> having an implicit `await Promise.resolve();` at the beginning of every
> async function.
>
> This would not allow async functions to invoke callbacks for DOM events
> at all, without wrapping them in a normal function. Using an async
> function as an event handler directly wouldn't be a good practice
> anyways, because if the async function throws an exception it would
> lead to an unhandled rejection, as if the `.catch()` in the example above
> was missing.
>
> Is the current scheduling a deliberate choice?
>
> I'm asking because async functions have just been implemented in the
> Mozilla JS engine, and it would be good to know that this is what we
> want before async functions get widespread use in our codebase.
>
> Cheers,
> Paolo
> _______________________________________________
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
--
Jeremy Martin
661.312.3853
http://devsmash.com
@jmar777
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
