Anti-pattern Analysis of Using async/await Inside Promise Constructor

Introduction

In modern JavaScript asynchronous programming, async/await and Promises are core mechanisms. However, improper combination can lead to anti-patterns, especially when using async/await inside Promise constructors. Based on Stack Overflow Q&A data, this article analyzes the essence, risks, and solutions of this anti-pattern.

Definition and Risks of Anti-pattern

The Promise constructor anti-pattern involves nesting Promises or async/await within the executor function. The primary risk is unsafe error propagation. In standard Promise constructors, immediate exceptions in the executor are automatically caught, rejecting the new Promise. For example:

let p = new Promise(resolve => {
  ""(); // TypeError
  resolve();
});

(async () => {
  await p;
})().catch(e => console.log("Caught: " + e)); // Catches exception

Yet, when the executor is marked async, the behavior changes:

let p = new Promise(async resolve => {
  ""(); // TypeError
  resolve();
});

(async () => {
  await p;
})().catch(e => console.log("Caught: " + e)); // Does not catch exception

This occurs because async functions return an implicit Promise, whose exceptions reject that implicit Promise, not the outer constructed one. Since Promise constructors ignore the executor's return value, exceptions fail to propagate correctly.

Code Example Analysis

Consider the original code:

function myFunction() {
 return new Promise(async (resolve, reject) => {
   eachLimit((await getAsyncArray), 500, (item, callback) => {
     // Other operations using native Promises
   }, (error) => {
     if (error) return reject(error);
     // Resolve here passing the next value
   });
 });
}

Here, myFunction returns a Promise with an async executor, introducing the above error propagation risk and violating Promise best practices.

Improvement Strategies

To avoid the anti-pattern, define myFunction as an async function for safer async integration:

async function myFunction() {
  let array = await getAsyncArray();
  return new Promise((resolve, reject) => {
    eachLimit(array, 500, (item, callback) => {
      // Other operations using native Promises
    }, error => {
      if (error) return reject(error);
      // Resolve here passing the next value
    });
  });
}

This refactoring ensures errors propagate correctly through the Promise chain while maintaining code clarity. Moreover, in modern JavaScript, consider using native async/await over outdated concurrency libraries to simplify async flows.

Supplementary References

Other answers suggest alternatives, such as wrapping an async function in an IIFE inside the Promise constructor:

let p = new Promise((resolve, reject) => {
  (async () => {
    try {
      const op1 = await operation1;
      const op2 = await operation2;
      if (op2 == null) {
         throw new Error('Validation error');
      }
      const res = op1 + op2;
      const result = await publishResult(res);
      resolve(result);
    } catch (err) {
      reject(err);
    }
  })();
});

This avoids lint errors and allows sequential async calls but requires manual try/catch and reject handling, adding complexity.

Conclusion

Using async/await inside Promise constructors is an anti-pattern, primarily risking failed error propagation. By defining outer functions as async and refactoring appropriately, this issue can be avoided. Developers should prioritize modern async mechanisms and adhere to Promise design principles for reliable and maintainable code.