Wann gilt .then(Erfolg, Misserfolg) als Antimuster für Versprechungen?

Ich habe mir die angeschaut Häufig gestellte Fragen zum Bluebird-Versprechenin dem das erwähnt wird .then(success, fail) ist ein Antimuster. Ich verstehe die Erklärung für die nicht ganz try und catch. Was ist an folgendem falsch?

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

Es scheint, dass das Beispiel das Folgende als den richtigen Weg vorschlägt.

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

Was ist der Unterschied?

Was ist der Unterschied?

Die .then() call gibt ein Promise zurück, das abgelehnt wird, falls der Callback einen Fehler auslöst. Das bedeutet, wenn Ihr Erfolg logger fehlschlägt, wird der Fehler an Folgendes weitergegeben .catch() Rückruf, aber nicht an die fail Rückruf, der daneben geht success.

Hier ist ein Kontrollfluss Diagramm:

Um es in synchronem Code auszudrücken:

// 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);
}

Der Zweite log (was wie das erste Argument zu ist .then()) wird nur ausgeführt, wenn keine Ausnahme aufgetreten ist. Der beschriftete Block und die break Anweisung fühlt sich etwas seltsam an, das ist eigentlich das, was Python hat try-except-else für (Leseempfehlung!).

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

Die catch logger behandelt auch Ausnahmen vom erfolgreichen Logger-Aufruf.

So viel zum Unterschied.

Ich verstehe die Erklärung für das Try and Catch nicht ganz

Das Argument ist, dass Sie normalerweise Fehler in jedem Schritt der Verarbeitung abfangen möchten und dass Sie es nicht in Ketten verwenden sollten. Die Erwartung ist, dass Sie nur einen letzten Handler haben, der alle Fehler behandelt – während bei Verwendung des “Antimusters” Fehler in einigen der Then-Callbacks nicht behandelt werden.

Dieses Muster ist jedoch sehr nützlich: Wenn Sie Fehler behandeln möchten, die in genau diesem Schritt aufgetreten sind, und etwas tun möchten ganz anders wenn kein Fehler aufgetreten ist – dh wenn der Fehler nicht behebbar ist. Sei vorsichtig dass das ist Verzweigung Ihr Kontrollfluss. Natürlich ist dies manchmal erwünscht.

Was ist an folgendem falsch?

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

Dass Sie Ihren Rückruf wiederholen mussten. Du willst lieber

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

Sie könnten auch die Verwendung von in Betracht ziehen .finally() dafür.

Die beiden sind nicht ganz identisch. Der Unterschied besteht darin, dass das erste Beispiel keine Ausnahme abfängt, die in Ihrem ausgelöst wird success Handler. Wenn Ihre Methode also immer nur aufgelöste Promises zurückgeben soll, wie es oft der Fall ist, benötigen Sie ein Trailing catch Handler (oder noch ein anderer then mit einem leeren success Parameter). Sicher, es kann sein, dass Ihre then Der Handler tut nichts, was möglicherweise fehlschlagen könnte, in diesem Fall wird ein 2-Parameter verwendet then könnte gut sein.

Aber ich glaube, der Punkt des Textes, auf den Sie verlinkt haben, ist das then ist im Vergleich zu Rückrufen am nützlichsten, da es möglich ist, eine Reihe asynchroner Schritte zu verketten, und wenn Sie dies tatsächlich tun, die 2-Parameter-Form von then subtil verhält sich aus dem oben genannten Grund nicht ganz wie erwartet. Es ist besonders kontraintuitiv, wenn es in der Mitte der Kette verwendet wird.

Als jemand, der viel komplexes asynchrones Zeug gemacht hat und öfter auf solche Ecken gestoßen ist, als ich zugeben möchte, empfehle ich wirklich, dieses Anti-Pattern zu vermeiden und den separaten Handler-Ansatz zu wählen.

Indem wir die Vor- und Nachteile beider betrachten, können wir eine kalkulierte Vermutung anstellen, welche für die Situation angemessen ist. Dies sind die beiden Hauptansätze zur Umsetzung von Versprechen. Beides hat seine Vor- und Nachteile

Fangansatz

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

Vorteile

1. Alle Fehler werden von einem Catch-Block behandelt.
2. Fängt sogar jede Ausnahme im then-Block ab.
3. Verkettung mehrerer Erfolgsrückrufe

Nachteile

1. Bei Verkettung wird es schwierig, unterschiedliche Fehlermeldungen anzuzeigen.

Erfolgs-/Fehleransatz

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

Vorteile

1. Sie erhalten eine feinkörnige Fehlerkontrolle.
2. Sie können eine gemeinsame Fehlerbehandlungsfunktion für verschiedene Fehlerkategorien wie DB-Fehler, 500-Fehler usw. haben.

Nachteile

1. Sie werden noch eine andere brauchen catch wenn Sie Fehler behandeln möchten, die vom Erfolgs-Callback ausgelöst werden

Einfach erklären:

Im ES2018

Wenn die catch-Methode mit dem Argument onRejected aufgerufen wird, werden die folgenden Schritte ausgeführt:

1. Lassen Sie das Versprechen der this-Wert sein.
2. Zurückkehren ? Invoke(promise, “then”, « undefined, onRejected »).

das bedeutet:

promise.then(f1).catch(f2)

gleich

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

Verwenden .then().catch() können Sie aktivieren Versprechen Verkettung die zur Erfüllung eines Workflows benötigt wird. Möglicherweise müssen Sie einige Informationen aus der Datenbank lesen, dann möchten Sie sie an eine asynchrone API übergeben und dann die Antwort bearbeiten. Möglicherweise möchten Sie die Antwort zurück in die Datenbank übertragen. Die Handhabung all dieser Workflows mit Ihrem Konzept ist machbar, aber sehr schwer zu verwalten. Die bessere Lösung wird sein then().then().then().then().catch() der alle Fehler auf einmal auffängt und Sie behalten lässt Wartbarkeit des Codes.

Verwenden then() und catch() hilft Kettenerfolg und Misserfolg Handler auf das Versprechen.catch() funktioniert auf Versprechen zurückgegeben von then(). Es handhabt,

1. Wenn das Versprechen abgelehnt wurde. Siehe Nr. 3 im Bild
2. Wenn im Erfolgshandler von then() ein Fehler aufgetreten ist, zwischen den Zeilennummern 4 bis 7 unten. Siehe #2.a im Bild (Failure callback on then() verarbeitet das nicht.)
3. Wenn ein Fehler in der Fehlerbehandlung von then() aufgetreten ist, Zeile Nummer 8 unten. Siehe #3.b im Bild.


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. });

Notiz: Häufig ist der Fehlerbehandler möglicherweise nicht definiert, wenn catch() ist schon geschrieben. BEARBEITEN: reject() zum Aufruf führen catch() nur wenn der errorhandler in then() ist nicht definiert. Beachten Sie # 3 im Bild zum catch(). Es wird aufgerufen, wenn Handler in Zeile 8 und 9 nicht definiert sind.

Es macht Sinn, weil das Versprechen zurückgegeben wird then() hat keinen Fehler, wenn ein Callback sich darum kümmert.

Statt Worte, gutes Beispiel. Folgender Code (wenn erstes Versprechen gelöst):

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

ist identisch mit:

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

Aber mit abgelehntem ersten Versprechen ist dies nicht identisch:

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'); }
)