Quand le .then (succès, échec) est-il considéré comme un anti-modèle des promesses?

J'ai jeté un coup d'œil à la FAQ sur la promesse bluebird , dans laquelle il mentionne que .then(success, fail)c'est un anti-modèle . Je ne comprends pas très bien son explication quant au try and catch. Quel est le problème avec ce qui suit?

some_promise_call()
.then(function(res) { logger.log(res) }, function(err) { logger.log(err) })

Il semble que l'exemple suggère ce qui suit comme la bonne manière.

some_promise_call()
.then(function(res) { logger.log(res) })
.catch(function(err) { logger.log(err) })

Quelle est la différence?

Quelle est la différence?

L' .then()appel renverra une promesse qui sera rejetée au cas où le rappel génère une erreur. Cela signifie que lorsque votre succès loggeréchoue, l'erreur sera transmise au .catch()rappel suivant , mais pas au failrappel associé à success.

Voici un diagramme de flux de contrôle :

Pour l'exprimer en code synchrone:

// some_promise_call().then(logger.log, logger.log)
then: {
    try {
        var results = some_call();
    } catch(e) {
        logger.log(e);
        break then;
    } // else
        logger.log(results);
}

Le second log(qui est comme le premier argument .then()) ne sera exécuté que dans le cas où aucune exception ne se produirait. Le bloc étiqueté et l' breakinstruction semblent un peu bizarres, c'est en fait ce que Python a try-except-elsepour (lecture recommandée!).

// some_promise_call().then(logger.log).catch(logger.log)
try {
    var results = some_call();
    logger.log(results);
} catch(e) {
    logger.log(e);
}

L' catchenregistreur gérera également les exceptions de l'appel de l'enregistreur de succès.

Voilà pour la différence.

Je ne comprends pas tout à fait son explication quant au try and catch

L'argument est que vous souhaitez généralement détecter les erreurs à chaque étape du traitement et que vous ne devez pas l'utiliser en chaîne. On s'attend à ce que vous n'ayez qu'un seul gestionnaire final qui gère toutes les erreurs - alors que, lorsque vous utilisez le "antipattern", les erreurs dans certains des rappels ne sont pas gérées.

Cependant, ce modèle est en fait très utile: lorsque vous voulez gérer des erreurs qui se sont produites exactement à cette étape, et que vous voulez faire quelque chose de complètement différent quand aucune erreur ne s'est produite - c'est-à-dire lorsque l'erreur est irrécupérable. Sachez que cela branche votre flux de contrôle. Bien sûr, cela est parfois souhaité.

Quel est le problème avec ce qui suit?

some_promise_call()
.then(function(res) { logger.log(res) }, function(err) { logger.log(err) })

Que vous deviez répéter votre rappel. Tu veux plutôt

some_promise_call()
   .catch(function(e) {
       return e; // it's OK, we'll just log it
   })
   .done(function(res) {
       logger.log(res);
   });

Vous pouvez également envisager d'utiliser .finally()pour cela.

Les deux ne sont pas tout à fait identiques. La différence est que le premier exemple n'attrapera pas une exception levée dans votre successgestionnaire. Donc, si votre méthode ne doit jamais renvoyer que des promesses résolues, comme c'est souvent le cas, vous avez besoin d'un catchgestionnaire de fin (ou encore d'un autre thenavec un successparamètre vide ). Bien sûr, il se peut que votre thengestionnaire ne fasse rien qui puisse potentiellement échouer, auquel cas l'utilisation d'un paramètre à 2 thenpeut être bien.

Mais je pense que le point du texte que vous avez lié est qu'il thenest surtout utile par rapport aux rappels dans sa capacité à enchaîner un tas d'étapes asynchrones, et lorsque vous faites cela, la forme à 2 paramètres de thensubtilement ne se comporte pas comme prévu , pour la raison ci-dessus. Il est particulièrement contre-intuitif lorsqu'il est utilisé à mi-chaîne.

En tant que personne qui a fait beaucoup de trucs asynchrones complexes et qui s'est cogné dans des coins comme celui-ci plus que je ne veux l'admettre, je recommande vraiment d'éviter cet anti-pattern et d'adopter l'approche du gestionnaire séparé.

En examinant les avantages et les inconvénients des deux, nous pouvons faire une estimation calculée de ce qui convient à la situation. Ce sont les deux principales approches de mise en œuvre des promesses. Les deux ont ses avantages et ses inconvénients

Approche de capture

some_promise_call()
.then(function(res) { logger.log(res) })
.catch(function(err) { logger.log(err) })

Avantages

1. Toutes les erreurs sont gérées par un bloc catch.
2. Attrape même toute exception dans le bloc then.
3. Chaînage de plusieurs rappels de succès

Désavantages

1. En cas de chaînage, il devient difficile d'afficher différents messages d'erreur.

Approche succès / erreur

some_promise_call()
.then(function success(res) { logger.log(res) },
      function error(err) { logger.log(err) })

Avantages

1. Vous obtenez un contrôle d'erreur précis.
2. Vous pouvez avoir une fonction de gestion des erreurs commune pour diverses catégories d'erreurs telles que l'erreur db, l'erreur 500, etc.

Inconvénients

1. Vous en aurez toujours besoin catchsi vous souhaitez gérer les erreurs générées par le rappel de réussite

Expliquez simplement:

Dans ES2018

Lorsque la méthode catch est appelée avec l'argument onRejected, les étapes suivantes sont effectuées:

1. Que la promesse soit cette valeur.
2. Revenir ? Invoke (promesse, "alors", "indéfini, onRejected").

cela signifie:

promise.then(f1).catch(f2)

équivaut à

promise.then(f1).then(undefiend, f2)

L'utilisation .then().catch()vous permet d'activer le chaînage des promesses qui est nécessaire pour exécuter un flux de travail. Vous devrez peut-être lire certaines informations de la base de données, puis vous souhaitez les transmettre à une API asynchrone, puis vous souhaitez manipuler la réponse. Vous souhaiterez peut-être repousser la réponse dans la base de données. Gérer tous ces flux de travail avec votre concept est faisable mais très difficile à gérer. La meilleure solution sera de then().then().then().then().catch()recevoir toutes les erreurs en une seule fois et de conserver la maintenabilité du code.

Utiliser then()et catch()aider à enchaîner le succès et le gestionnaire d'échec sur la promesse catch()travaux sur promesse retournés par then(). Il gère,

1. Si la promesse était rejetée. Voir le n ° 3 sur l'image
2. Si une erreur s'est produite dans le gestionnaire de succès de then (), entre les numéros de ligne 4 à 7 ci-dessous. Voir # 2.a sur l'image (le rappel d'échec sur then()ne gère pas cela.)
3. Si une erreur s'est produite dans le gestionnaire d'échec de then (), ligne numéro 8 ci-dessous. Voir # 3.b sur l'image.

1. let promiseRef: Promise = this. aTimetakingTask (false); 2. promiseRef 3. .then( 4. (result) => { 5. /* successfully, resolved promise. 6. Work on data here */ 7. }, 8. (error) => console.log(error) 9. ) 10. .catch( (e) => { 11. /* successfully, resolved promise. 12. Work on data here */ 13. });

Remarque : Plusieurs fois, le gestionnaire d'échec peut ne pas être défini s'il catch()est déjà écrit. EDIT: reject()n'invoque catch()que si le gestionnaire d'erreurs then()n'est pas défini. Remarquez # 3 sur l'image au catch(). Il est appelé lorsque le gestionnaire des lignes 8 et 9 n'est pas défini.

Cela a du sens car la promesse renvoyée par then()n'a pas d'erreur si un rappel en prend soin.

Au lieu de mots, bon exemple. Code suivant (si première promesse résolue):

Promise.resolve()
.then
(
  () => { throw new Error('Error occurs'); },
  err => console.log('This error is caught:', err)
);

est identique à:

Promise.resolve()
.catch
(
  err => console.log('This error is caught:', err)
)
.then
(
  () => { throw new Error('Error occurs'); }
)

Mais avec la première promesse rejetée, ce n'est pas identique:

Promise.reject()
.then
(
  () => { throw new Error('Error occurs'); },
  err => console.log('This error is caught:', err)
);

Promise.reject()
.catch
(
  err => console.log('This error is caught:', err)
)
.then
(
  () => { throw new Error('Error occurs'); }
)