Stellen Sie sich eine Webanwendung mit Routen vor, die überprüfen müssen, ob der Benutzer auf eine bestimmte Ressource zugreifen darf, bevor er fortfährt. Die Prüfung "ist authentifiziert" beruht auf einem Datenbankaufruf.
In jeder Route habe ich vielleicht:
%Vor% Ich möchte, dass die Funktion authorizeOwnership() 403 (Zugriff verweigert) und 500 (z. B. Datenbankabfragefehler) behandelt, so dass jede Route dies nicht explizit ausführen muss.
Ich habe eine Funktion, die die Datenbank abfragen kann, um nach dem Besitz zu suchen.
%Vor% Dies wird dann in authorizeOwnership :
In diesem Szenario werde ich in einigen Codepfaden absichtlich nicht reject() oder resolve() aufrufen. Wenn ich das tue, wird meine "äußere" Routenlogik (der Code, der authorizeOwnership() aufruft) komplizierter, weil sie Fehler behandeln muss (entweder mit einem .catch() oder mit einem null check in .then() ).
Zwei Dinge machen mich allerdings ein bisschen nervös:
Ist es in Ordnung, dass das Versprechen von authorizeOwnership() in Fehlerszenarien nicht aufgelöst wird? Wird es eine Verzögerung oder einen Speicherverlust verursachen?
Ist es logisch, confirmOwnership() mit null aufzulösen, um "no matching resource found" zu sagen und das dann als Fehler in authorizeOwnership() zu behandeln? Mein erster Versuch lehnte das Versprechen in confirmOwnership() ab, wenn es keine übereinstimmende Ressource gab, aber dies machte die Dinge komplizierter, weil es schwierig ist, zwischen diesem (dem Fall 403) und einem tatsächlichen Fehler (dem Fall 500) zu unterscheiden.
Ist es in Ordnung, dass die von authorizeOwnership () zurückgegebene Zusage in Fehlerszenarien niemals gelöst wird? Wird es eine Verzögerung oder einen Speicherverlust verursachen?
Ja, es ist sicher, ein Bluebird-Versprechen nicht zu lösen (und fair zu sein, jede andere Implementierung, die ich überprüft habe - schöne Bilder hier ). Es hat keinen globalen Staat für sich.
Die Frage, ob es eine gute Praxis ist oder nicht, ist anders. Es ist wie eine synchrone break in gewissem Sinne. Persönlich bin ich kein Fan.
Ist es logisch, confirmOwnership () mit null aufzulösen, um "keine übereinstimmende Ressource gefunden" zu sagen, und dies dann als Fehler in authorizeOwnership () zu behandeln?
Dies hängt von Ihrer API ab. Es ist wieder eine Meinung. Es funktioniert, aber ich würde wahrscheinlich nicht null zurückgeben, sondern einen Fehler anzeigen, wenn der Fall außergewöhnlich ist. Sie können die Zurückweisung anhand eines Fehlerobjekts unterscheiden. Sie können dies mit einem AuthorizationError -Objekt ablehnen, das Sie beispielsweise anlegen. Hinweis Bluebird unterstützt auch typisierte Fänge.
Etwas wie:
%Vor%Als nächstes können Sie auf Ihrem Server Folgendes tun:
%Vor% Hinweis: Sie verwenden das deferred anti-Muster auch in Ihrem Code. Sie müssen new Promise(function(...){ nicht in Ihrem Code eingeben, Sie können einfach das Versprechen zurückgeben.