Kiedy .ten (sukces, porażka) jest uważany za antypattern dla obietnic?

Rzuciłem okiem na często zadawane pytania dotyczące obietnicy bluebird , w których wspomina, że .then(success, fail)jest to antypattern . Nie do końca rozumiem jego wyjaśnienie dotyczące próby złapania. Co jest z tym nie tak?

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

Wygląda na to, że przykład sugeruje następujące postępowanie jako prawidłowy sposób.

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

Co za różnica?

Co za różnica?

.then()Rozmowa powróci obietnicę, że zostanie odrzucona w przypadku oddzwaniania zgłasza błąd. Oznacza to, że gdy Twój sukces się loggernie powiedzie, błąd zostanie przekazany do następującego .catch()wywołania zwrotnego, ale nie do failwywołania zwrotnego, które towarzyszy success.

Oto schemat kontrolny :

Aby wyrazić to w kodzie synchronicznym:

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

Drugi log(który jest jak pierwszy argument .then()) zostanie wykonany tylko w przypadku, gdy nie wystąpi żaden wyjątek. Znakowany blok i breakoświadczenie czujesz się trochę dziwne, to jest rzeczywiście to, co python ma try-except-elsedla (zalecane lektury!).

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

Program catchrejestrujący będzie także obsługiwał wyjątki od wywołania programu rejestrującego sukces.

Tyle o różnicy.

Nie do końca rozumiem jego wyjaśnienie dotyczące próby złapania

Argument jest taki, że zwykle chcesz wychwytywać błędy na każdym etapie przetwarzania i że nie powinieneś używać go w łańcuchach. Oczekuje się, że masz tylko jeden końcowy moduł obsługi, który obsługuje wszystkie błędy - podczas gdy podczas korzystania z „antipattern” błędy w niektórych wywołaniach zwrotnych nie są obsługiwane.

Jednak ten wzorzec jest w rzeczywistości bardzo przydatny: gdy chcesz obsłużyć błędy, które wystąpiły dokładnie w tym kroku, i chcesz zrobić coś zupełnie innego, gdy nie wystąpił błąd - tj. Gdy błąd jest nie do naprawienia. Pamiętaj, że to rozgałęzia twój przepływ kontroli. Oczywiście jest to czasem pożądane.

Co jest z tym nie tak?

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

Że musisz powtórzyć oddzwonienie. Raczej chcesz

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

Możesz również rozważyć użycie .finally()do tego celu.

Te dwa nie są do końca identyczne. Różnica polega na tym, że pierwszy przykład nie złapie wyjątku zgłoszonego w successmodule obsługi. Tak więc, jeśli twoja metoda powinna zwracać tylko rozwiązane obietnice, jak to często bywa, potrzebujesz końcowej catchprocedury obsługi (lub jeszcze innej thenz pustym successparametrem). Jasne, może się zdarzyć, że twój thenprogram obsługi nie zrobi niczego, co mogłoby potencjalnie zawieść, w takim przypadku użycie jednego 2-parametru thenmoże być w porządku.

Uważam jednak, że sens tekstu, do którego się odnosisz, thenjest najbardziej przydatny w porównaniu do wywołań zwrotnych w jego zdolności do łączenia szeregu asynchronicznych kroków, a kiedy faktycznie to robisz, 2-parametrowa forma thensubtelnie nie zachowuje się tak, jak się spodziewano , z powyższego powodu. Jest to szczególnie sprzeczne z intuicją, gdy jest używane w połowie łańcucha.

Jako ktoś, kto wykonał wiele skomplikowanych zadań asynchronicznych i wpadł na takie zakręty bardziej, niż się to przyznaję, naprawdę zalecam unikanie tego anty-wzorca i stosowanie osobnego podejścia obsługi.

Patrząc na zalety i wady obu tych elementów, możemy wyliczyć, które z nich jest odpowiednie w danej sytuacji. Są to dwa główne podejścia do realizacji obietnic. Oba mają swoje plusy i minusy

Podejście połowowe

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

Zalety

1. Wszystkie błędy są obsługiwane przez jeden blok catch.
2. Nawet wyłapuje dowolny wyjątek w tym bloku.
3. Łączenie wielu zwrotnych sukcesów

Niedogodności

1. W przypadku tworzenia łańcuchów trudno jest wyświetlać różne komunikaty o błędach.

Podejście do sukcesu / błędu

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

Zalety

1. Otrzymujesz precyzyjną kontrolę błędów.
2. Możesz mieć wspólną funkcję obsługi błędów dla różnych kategorii błędów, takich jak błąd db, błąd 500 itp.

Wady

1. Nadal będziesz potrzebować innego, catchjeśli chcesz obsługiwać błędy generowane przez wywołanie zwrotne sukcesu

Proste wyjaśnienie:

W ES2018

Po wywołaniu metody catch z argumentem onRejected podejmowane są następujące kroki:

1. Obiecajmy, że ta wartość będzie.
2. Powrót ? Wywołaj (obiecaj, „następnie”, «niezdefiniowany, onRejected»).

to znaczy:

promise.then(f1).catch(f2)

równa się

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

Użycie .then().catch()pozwala włączyć Łańcuch obietnicy, który jest wymagany do realizacji przepływu pracy. Może być konieczne odczytanie niektórych informacji z bazy danych, a następnie przekazanie ich do asynchronicznego interfejsu API, a następnie manipulowanie odpowiedzią. Możesz zepchnąć odpowiedź z powrotem do bazy danych. Obsługa wszystkich tych przepływów pracy za pomocą koncepcji jest wykonalna, ale bardzo trudna do zarządzania. Lepszym rozwiązaniem będzie then().then().then().then().catch()otrzymywanie wszystkich błędów za jednym razem catch i pozwala zachować łatwość konserwacji kodu.

Korzystanie then()i catch()pomoc w łańcuchu obsługi sukcesu i niepowodzenia w obietnicy. catch()działa na podstawie obietnicy zwróconej przez then(). Radzi sobie,

1. Jeśli obietnica została odrzucona. Zobacz nr 3 na zdjęciu
2. Jeśli wystąpił błąd w module obsługi sukcesu funkcji then (), między numerami linii od 4 do 7 poniżej. Zobacz # 2.a na zdjęciu (funkcja oddzwaniania w przypadku niepowodzenia then()tego nie obsługuje).
3. Jeśli wystąpił błąd w module obsługi błędów funkcji then (), wiersz 8 poniżej. Zobacz # 3.b na zdjęciu.

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

Uwaga : Wiele razy program obsługi błędów może nie zostać zdefiniowany, jeśli catch()jest już napisany. EDYCJA: reject()powoduje wywołanie catch()tylko wtedy, gdy procedura obsługi błędów w niethen() jest zdefiniowana. Zauważ # 3 na zdjęciu do . Jest wywoływany, gdy moduł obsługi w linii 8 i 9 nie jest zdefiniowany.catch()

Ma to sens, ponieważ zwrócona przez then()nie obietnica nie zawiera błędu, jeśli zajmuje się nią wywołanie zwrotne.

Zamiast słów dobry przykład. Poniższy kod (jeśli pierwsza obietnica została rozwiązana):

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

jest identyczny z:

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

Ale przy odrzuconej pierwszej obietnicy nie jest to identyczne:

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