Why does JavaScript Promise then handler run after other code?

by

The relevant specs are here:

  1. Promises/A+ point 2.2.4:

    onFulfilled or onRejected must not be called until the execution context stack contains only platform code. [3.1].

    And note 3.1 (emphasis mine):

    Here “platform code” means engine, environment, and promise implementation code. In practice, this requirement ensures that onFulfilled and onRejected execute asynchronously, after the event loop turn in which then is called, and with a fresh stack. This can be implemented with either a “macro-task” mechanism such as setTimeout or setImmediate, or with a “micro-task” mechanism such as MutationObserver or process.nextTick. Since the promise implementation is considered platform code, it may itself contain a task-scheduling queue or “trampoline” in which the handlers are called.

  2. ECMAScript 6.0 (based on Promises/A+) is a little harder to excerpt cleanly, but then resolves as in section 25.4.5.3.1:

    1. Else if the value of promise‘s [[PromiseState]] internal slot is "fulfilled",

      a. Let value be the value of promise‘s [[PromiseResult]] internal slot.

      b. Perform EnqueueJob("PromiseJobs", PromiseReactionJob, «‍fulfillReaction, value»).

    2. Else if the value of promise’s [[PromiseState]] internal slot is "rejected",

      a. Let reason be the value of promise‘s [[PromiseResult]] internal slot.

      b. Perform EnqueueJob("PromiseJobs", PromiseReactionJob, «‍rejectReaction, reason»).

    And the important EnqueueJob operation is defined in section 8.4 (“Jobs and Job Queues”), featuring this in its preface (bold is mine):

    Execution of a Job can be initiated only when there is no running execution context and the execution context stack is empty. […] Once execution of a Job is initiated, the Job always executes to completion. No other Job may be initiated until the currently running Job completes.

In practice, this lets you make a few simple and consistent statements:

  • You can count on then or catch (etc) to always behave asynchronously, never synchronously.
  • You’ll never see multiple then or catch handlers on the same stack, even if one Promise is explicitly resolved within another Promise. This also means that recursive Promise execution doesn’t risk stack overflows as a normal function call might, though you can still run out of heap space if you’re careless with recursive closures in a pathological case.
  • Time-consuming operations queued in a then or catch handler will never block the current thread, even if the Promise is already settled, so you can queue up a number of asynchronous operations without worrying about the order or promise state.
  • There will never be an enclosing try block outside of a then or catch, even when calling then on an already-settled Promise, so there’s no ambiguity about whether the platform should handle a thrown exception.

More Related Contents:

  1. How to return many Promises and wait for them all before doing other stuff
  2. When is the body of a Promise executed?
  3. ES6 Promise.all() error handle – Is .settle() needed? [duplicate]
  4. Why does the Promise constructor require a function that calls ‘resolve’ when complete, but ‘then’ does not – it returns a value instead?
  5. What is the best general practice to timeout a function in promise [closed]
  6. When would someone need to create a deferred?
  7. Promises, pass additional parameters to then chain
  8. How to extract data out of a Promise
  9. Are JavaScript forever-pending promises bad?
  10. Why does javascript ES6 Promises continue execution after a resolve?
  11. ES6 Promise replacement of async.eachLimit / async.mapLimit
  12. When is the body of a Promise constructor callback executed?
  13. What is the explicit promise construction antipattern and how do I avoid it?
  14. Cancel a vanilla ECMAScript 6 Promise chain
  15. fetch: Reject promise with JSON error object
  16. How to check if an object is a Promise?
  17. What do double brackets mean in javascript and how to access them
  18. How to know when all Promises are Resolved in a dynamic “iterable” parameter?
  19. using a fetch inside another fetch in javascript
  20. Why is the response object from JavaScript fetch API a promise?
  21. What is the difference between “event loop queue” and “job queue”?
  22. Is there a way to tell if an ES6 promise is fulfilled/rejected/resolved? [duplicate]
  23. What are asynchronous functions in JavaScript? What is “async” and “await” in JavaScript?
  24. What is the intention behind clause 2.2.4 of Promise/A+ spec?
  25. ES6 promise execution order for returned values
  26. What happens if you don’t resolve or reject a promise?
  27. Promise and Promise.all(array) executed before array fulfilled [duplicate]
  28. Node.js: When to use Promises vs Callbacks
  29. How can I export promise result?
  30. Promise.resolve().then vs setImmediate vs nextTick

Leave a Comment