Ich habe bei der Arbeit eine Codebasis geerbt, die ungefähr ein Dutzend Beispiele für das folgende Muster enthält:
%Vor% Dabei ist backendService ein Angular-Dienst, der wiederum einen REST-Dienst über $http aufruft.
Hier ist meine Frage: Ist das Versuchen / Fangen wirklich notwendig? Wird es jemals ein Szenario geben, in dem ein bestimmter Fehler / eine Ausnahme ausgelöst wird, die% code_% der Verheißung nicht erfassen kann?
Dies war das Thema einer ganzen Debatte über das Team den ganzen Morgen, und die einzige Lösung, die wir gefunden haben ist, dass wir nicht denken, dass es notwendig ist, aber (a) es zu ändern bricht die Tests, die neben ihm geschrieben wurden (die auch geändert werden müssten), und (b) gut ... es ist defensive Codierung, nicht wahr? Es ist kein schlechtes Ding.
Die Vorzüge, es tatsächlich zu stören, es in Vergessenheit zu bringen, wenn es wichtigere Dinge zu tun gibt, sind nicht das, wonach ich frage. Ich möchte nur wissen, ob es ein vernünftiges Muster ist, wenn Versprechungen so herumgereicht werden (speziell in AngularJS, wenn das einen Unterschied macht), oder einfach nur Paranoia.
Verspätet Versprechen in AngularJS jede Ausnahme / Fehler?
Nein. Nur Ausnahmen, die von innerhalb von then / catch Rückrufen ausgelöst werden, werden automatisch abgefangen. Alle Fehler außerhalb von ihnen müssen explizit behandelt werden.
Wird es jemals ein Szenario geben, in dem ein bestimmter Fehler / eine Ausnahme ausgelöst wird, wenn die
.catchder Verheißung nicht abfangen kann?
Ja. Dieser backendService.getResults(input) -Aufruf kann eine Verheißung nicht zurückgeben , aber es kann eine Ausnahme auslösen. Oder es kommt nicht einmal so weit, wenn backendService null ist, und du bekommst ReferenceError oder .getResults ist keine Funktion und du bekommst TypeError .
ist das versuchen / fangen wirklich notwendig?
Nicht wirklich. In letzterem Fall, dass Ihr Code einen schwerwiegenden Fehler hat, ist es wahrscheinlich nicht wichtig zu werfen und abstürzen. Der erste Fall, dass backendService.getResults(input) wirft, wird stark verachtet. Asynchrone Funktionen sollten nie throw , sondern nur Versprechen zurückgeben - genau deshalb, weil Sie nicht zwei Fehler schreiben müssen Umgang mit Aussagen dann.
Nun ... es ist defensive Codierung, oder? Es ist kein schlechtes Ding.
Ja, ziemlich. Aber es ist hier fraglich. Eine synchrone Ausnahme ist wirklich unerwartet , nicht nur ein Dienst, dessen Fehler behandelt werden kann. Die Logging-Nachricht im Block catch sollte dies anzeigen.
Beachten Sie, dass es auch nicht defensiv genug ist. Es wird nicht der wahrscheinliche Fehler gefunden, bei dem getResults() zurückkehrt, aber etwas, das kein Versprechen ist. Aufruf von .then() auf das könnte werfen. Ebenso ist die if (promise !== null) zweifelhaft, da sie sich verbirgt, wenn null fälschlicherweise zurückgegeben wird (wir könnten wirklich try-catch-else hier).
ist das versuchen / fangen wirklich notwendig?
Nicht wirklich. Solange Ihr backendService.getResults() eine Zusage zurückgibt. Wie return $http(...)
Wird es jemals ein Szenario geben, in dem ein bestimmter Fehler / eine Ausnahme vorliegt? geworfen, dass die .catch der Verheißung nicht fangen kann?
Ich denke nicht, da jeder Fehler ein abgelehntes Versprechen sein wird, wird es in Ihren .catch() Handler
Nun ... es ist defensive Codierung, oder? Es ist kein schlechtes Ding.
Es kommt darauf an ... Javascript try / catch hat einige Performance-Probleme. Also, wenn Sie nur für die Sicherheit verwenden, könnten Sie es entfernen:)
Werfen Sie einen weiteren Blick auf Versuch-fangen-Diskussion hier, wenn Sie wünschen: Javascript Try-Catch Performance Vs. Fehler beim Überprüfen des Codes
Tags und Links javascript angularjs promise