‫Mann: In diesem Video implementieren wir jetzt
‫die globale Middleware zur Fehlerbehandlung, über die wir
‫gerade gesprochen haben.
‫Denken Sie also daran, dass
‫das Ziel darin besteht, eine Middleware-Funktion zu
‫schreiben, die in der Lage ist, Betriebsfehler wie diesen zu behandeln.
‫Okay, wenn ein Benutzer auf eine URL trifft, die nicht existiert, können
‫wir dies als Betriebsfehler betrachten, und wir behandeln
‫ihn in diesem Fall, indem wir diese
‫Antwort hier zurücksenden, oder?
‫Aber auch hier ist das Ziel, dies an einer zentralen Stelle zu tun.
‫Wir haben zum Beispiel ähnliche Sachen hier oben.
‫Wir haben hier also überall diese Schnipsel,
‫die die Fehler behandeln.
‫Also müssen wir hier den Etch-Block anschlagen, und wenn ein
‫Fehler auftritt, dann behandeln wir ihn,
‫indem wir diesen Fehler an den Client senden.
‫Und so wollen wir das alles
‫am Ende wieder loswerden und den Fehler in
‫einer zentralen Middleware behandeln.
‫Lassen Sie uns nun damit beginnen,
‫diese Middleware-Funktion tatsächlich aufzubauen.
‫Und in Express ist es eigentlich ganz einfach.
‫Denken Sie daran, wie ich Ihnen gesagt
‫habe, dass Express bereits standardmäßig mit
‫Middleware-Handlern ausgestattet ist.
‫Wie immer beginnen wir mit der App. use, okay, und
‫dann definieren wir hier unsere Middleware-Funktion.
‫Um eine Middleware zur Fehlerbehandlung
‫zu definieren, müssen wir der Middleware-Funktion nur
‫vier Argumente geben, und Express erkennt sie
‫dann automatisch als Middleware zur Fehlerbehandlung.
‫Rufen Sie es deshalb nur auf, wenn ein Fehler auftritt.
‫Und genau wie in vielen anderen Fällen ist
‫diese Middleware-Funktion eine Error-First-Funktion, was bedeutet, dass
‫das erste Argument
‫der
‫Fehler ist, und dann haben wir Request, Response und Next.
‫Durch die Angabe von vier Parametern weiß Express also
‫automatisch, dass diese gesamte Funktion hier
‫eine Middleware zur Fehlerbehandlung ist.
‫Lassen Sie uns nun den Code für diese Funktion hier implementieren und
‫danach zeige ich Ihnen, wie wir tatsächlich
‫einen Fehler erzeugen können, damit diese Middleware-Funktion tatsächlich
‫abgefangen wird.
‫Also zwei Schritte, zuerst erstellen wir die Middleware, dann
‫erstellen wir im zweiten
‫Schritt tatsächlich einen Fehler, damit diese Funktion abgefangen wird.
‫Und jetzt halten wir es hier ganz einfach.
‫Um diesen Fehler zu beheben, möchten
‫wir also nur eine Antwort an den Client zurücksenden.
‫Also res. Status, aber jetzt
‫wissen wir nicht wirklich, um welchen Statuscode es sich handelt, oder?
‫In diesem Fall ist es beispielsweise ein 404, aber
‫wir haben hier einige Fehler mit anderen Statuscodes.
‫Wir haben zum Beispiel eine 400 für schlechte Anfragen oder
‫wirklich alle möglichen anderen Codes.
‫Und deshalb wollen wir eigentlich
‫diesen Statuscode aus dem Fehlerobjekt lesen, in Ordnung?
‫Wenn wir diesen Fehler etwas später im
‫zweiten Schritt erstellen, werden
‫wir, wie ich Ihnen bereits sagte, diesen Statuscode für den Fehler definieren.
‫Sagen wir also Statuscode, und jetzt möchte ich hier einen
‫Standard definieren.
‫Weil es Fehler geben wird, die nicht von
‫uns kommen, weil es Fehler ohne Statuscode
‫geben wird, also Fehler, die nicht von
‫uns erstellt werden, sondern zum Beispiel an anderen Stellen
‫in der Notizanwendung.
‫Und ich weiß, das klingt im Moment etwas verwirrend, aber
‫Sie werden es in diesem Abschnitt sehen.
‫Lassen Sie uns diesen Standardstatuscode jetzt wirklich
‫definieren.
‫Also sagen wir, dass der Fehler. statuscode
‫ist gleich err. statuscode im Wesentlichen, wenn
‫er definiert ist oder der Code 500, was wiederum einen internen Serverfehler
‫bedeutet, und das ist normalerweise der Standard,
‫den wir verwenden.
‫Und genauso definieren wir auch den Status, sagen
‫wir also Fehler. Status ist gleich Fehler. Status, wenn es definiert
‫ist, und wenn nicht, ist es
‫ein Fehler.
‫Denken Sie also daran, dass ein Fehler besteht, wenn wir einen 500-Statuscode haben und wenn
‫es ein 400-Statuscode ist, dann ist es ein Fehler.
‫Hier in diesem 404 ist der Status zum Beispiel fehlgeschlagen.
‫Und so können wir
‫das jetzt hier verwenden, also Fehler. statuscode, und senden Sie dann etwas JSON, also sehr
‫ähnlich zu dem, was wir zuvor gemacht haben.
‫Also fangen wir mit dem Status an und lesen den Fehler ab. Status und die
‫Meldung wird auch von dem Fehler kommen.
‫Also irr. Nachricht und ich werde Ihnen in einer
‫Sekunde zeigen, wie das irrt. Message-Eigenschaft wird hier erstellt.
‫In Ordnung, aber im Moment ist dies unsere sehr einfache
‫Middleware zur Fehlerbehandlung.
‫Also ganz einfach, aber im Moment funktioniert es.
‫Und so nun der zweite Schritt, bei dem
‫wir tatsächlich einen Fehler erstellen.
‫Und das machen wir hier.
‫Also genau hier in dieser Funktion, die alle nicht
‫behandelten Routen verarbeitet, also lassen Sie mich
‫diese hier auskommentieren und stattdessen möchten wir einen Fehler erstellen.
‫Sagen wir also const err und
‫es ist ein neuer Fehler.
‫Wir verwenden also grundsätzlich den eingebauten Fehlerkonstruktor, um
‫einen Fehler zu erzeugen.
‫Und jetzt können wir einen String übergeben und
‫dieser String wird dann die Fehlermeldungseigenschaft sein.
‫Also worüber wir gerade hier unten gesprochen haben.
‫Diese Nachricht sollte also diese Nachricht sein.
‫Gut?
‫Und dann sollte es Fehler sagen. Status, der
‫fehlgeschlagen
‫ist, und dann err. statusCode ist gleich 404.
‫Das habe ich bereits erwähnt, dass wir den
‫Statuscode und den Status des Fehlerobjekts definieren können.
‫Und genau das tun wir hier.
‫Wir erstellen einen Fehler und
‫definieren dann die Status- und Statuscode-Eigenschaften, damit unsere
‫Middleware zur Fehlerbehandlung
‫sie im nächsten Schritt verwenden kann.
‫Aber wie lesen wir nun diesen nächsten Schritt eigentlich?
‫Damit die nächste Middleware.
‫Nun, wie immer verwenden wir next.
‫Aber dieses Mal verwenden wir next in besonderer Weise.
‫Denn jetzt müssen wir diesen Fehler tatsächlich
‫an next übergeben. Wenn also die nächste Funktion ein
‫Argument empfängt, egal was es ist,
‫erkennt Express automatisch, dass ein Fehler aufgetreten ist, und
‫nimmt an, dass alles, was wir an next
‫übergeben, ein Error.
‫Und das gilt für jede weitere Funktion in jeder
‫einzelnen Middleware überall in unserer Anwendung.
‫Jedes Mal, wenn wir also etwas an next übergeben,
‫geht es davon aus, dass es sich um
‫einen Fehler handelt, überspringt dann alle anderen
‫Middlewares im Middleware-Stack und sendet den Fehler, den
‫wir übergeben haben, an unsere globale Fehlerbehandlungs-Middleware, die
‫dann , natürlich ausgeführt werden.
‫Und so lassen Sie uns
‫jetzt den Fehler überspringen, der wieder alle
‫anderen Middlewares im Stack überspringt und direkt zu dieser gehen.
‫In diesem Fall gibt
‫es eigentlich keine andere Middleware in der Mitte, okay?
‫Es ist also wirklich nur
‫das nächste hier, aber wenn wir next verwenden und
‫woanders einen Fehler eingeben, dann funktioniert es natürlich genauso.
‫Lassen Sie uns all dies nun einfach
‫testen, indem wir versuchen, auf eine nicht definierte Route zuzugreifen.
‫Damit wird dann der gesamte Code hier ausgelöst,
‫zur Fehlerbehandlungs-Middleware gesprungen und dann die Antwort
‫basierend auf dieser ganzen Logik
‫hier zurückgesendet.
‫Also, hier haben wir immer noch unsere falsche oder nicht vorhandene Route
‫und lasst uns damit beginnen, dass wir tatsächlich
‫diese anrufen, die noch funktionieren
‫sollte, okay, also nur um
‫zu bestätigen, dass alles gut funktioniert und es funktioniert,
‫und jetzt diese.
‫Und tatsächlich bekommen wir auf diesem Server keine API-Slash-Touren, und so
‫erledigt unsere globale Middleware zur Fehlerbehandlung
‫tatsächlich ihre Arbeit.
‫Perfekt, das ist der erste Schritt, um wirklich
‫einen viel besseren Fehlerbehandlungsmechanismus in unserer
‫Anwendung zu implementieren.
‫Wir könnten jetzt also weitermachen und versuchen, diese Art
‫von Sachen hier überall in all unseren Handlern
‫zu implementieren.
‫Zum Beispiel hier drüben in all diesen Funktionen, die wir
‫hier haben.
‫Ersetzen Sie also alles, was wir hier haben, durch
‫diese Art von Fehler.
‫Aber was ich vorerst tun möchte, ist, unsere
‫eigene Fehlerklasse zu erstellen.
‫Damit wir nicht den ganzen Code hier schreiben müssen
‫und stattdessen eine eher schlanke Klasse von uns
‫haben.
‫Das ist also eine gängige Praxis, und das machen wir im
‫nächsten Video.