Pourquoi l'imbrication « async/await » dans les constructeurs de promesses est-elle un anti-modèle ?

L'anti-modèle d'imbrication async/wait dans les constructeurs de promesses

Dans ce cas, où la fonction async.eachLimit est utilisée pour gérer le nombre d'opérations simultanées, un dilemme se pose. La tentation initiale est de structurer le code comme suit :

function myFunction() {
  return new Promise(async (resolve, reject) => {
    eachLimit((await getAsyncArray), 500, (item, callback) => {
      // Operations using native promises
    }, (error) => {
      if (error) return reject(error);
      // Resolve with the next value
    });
  });
}

Bien qu'il puisse sembler logique de déclarer la fonction "myFunction" comme asynchrone, cela n'est pas réalisable car le rappel interne de la fonction "eachLimit" reste inaccessible. Cependant, cette approche pose un écueil important : le risque que des erreurs restent non gérées.

Cette approche est un exemple classique de l'anti-modèle qui implique l'utilisation de promesses au sein du constructeur d'une autre promesse. Dans ce cas, le risque d’erreurs non gérées est particulièrement aigu. Pour éviter cela, considérez l'extrait de code suivant :

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

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

Dans ce scénario, alors que la première ligne renvoie une exception, l'erreur est gérée gracieusement par le bloc "catch" de la fonction de flèche asynchrone. Une gestion appropriée des erreurs est essentielle pour maintenir la stabilité et éviter tout comportement inattendu dans votre base de code.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!