L'utilisation de « async/await » dans un constructeur « Promise » est-elle un anti-modèle ?

Est-ce un anti-modèle d'utiliser async/await à l'intérieur d'un nouveau constructeur Promise() ?

La programmation asynchrone peut être difficile, surtout lorsqu'il s'agit de rappels imbriqués. Pour simplifier cela, ES6 a introduit la syntaxe async/await. Cependant, lors de l'utilisation de async/await dans la fonction constructeur d'un new Promise(), la prudence est de mise.

Dans l'exemple fourni :

return new Promise(async (resolve, reject) => {
  eachLimit((await getAsyncArray), 500, (item, callback) => {
    // do other things that use native promises.
  }, (error) => {
    if (error) return reject(error);
    // resolve here passing the next value.
  });
});

Vous utilisez wait pour appeler getAsyncArray , qui renvoie une promesse, mais dans la fonction d'exécution du constructeur Promise. C'est ce qu'on appelle « l'anti-modèle du constructeur de promesse ».

Le principal danger de ce modèle est que les erreurs pourraient ne pas être traitées correctement. L'asynchronicité peut créer un comportement imprévisible, et l'utilisation de async/await rend plus difficile la détection des problèmes potentiels.

Par exemple, une faute de frappe dans la fonction getAsyncArray entraînerait une TypeError, mais elle pourrait ne pas être détectée par le rappel eachLimit. gestion des erreurs. Cependant, si async/await était supprimé, l'erreur serait renvoyée en dehors du constructeur Promise et gérée de manière appropriée.

En conclusion, même si l'utilisation de async/await dans la fonction constructeur d'une Promise() peut sembler pratique, c'est un anti-modèle en raison du potentiel de problèmes de gestion des erreurs. Au lieu de cela, envisagez d'utiliser async/await en dehors du constructeur Promise pour garantir une propagation appropriée des erreurs et la maintenabilité du 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!