‫Kursleiter: Lassen Sie uns in diesem Video über
‫etwas sprechen, das wir in node. js namens unbehandelte Ablehnungen und
‫erfahren Sie dann, wie wir sie tatsächlich handhaben können.
‫An dieser Stelle haben wir Fehler in
‫unserer Express-Anwendung erfolgreich
‫behandelt, indem wir operative asynchrone Fehler an
‫eine globale Fehlerbehandlungs-Middleware weitergegeben haben.
‫Dieser sendet dann abhängig von der Art
‫des aufgetretenen Fehlers relevante Fehlermeldungen an den Client zurück, oder?
‫Es können jedoch auch Fehler außerhalb von Express auftreten
‫und ein gutes Beispiel dafür in unserer aktuellen
‫Anwendung ist die mongodb-Datenbankverbindung.
‫Stellen Sie sich also vor, die Datenbank ist aus irgendeinem Grund ausgefallen
‫oder wir können uns aus irgendeinem Grund nicht anmelden.
‫Und dann gibt es auch Fehler,
‫mit denen wir umgehen müssen.
‫Aber sie sind nicht in unserer Express-Anwendung aufgetreten und
‫daher wird unsere Fehlerbehandlung, die wir implementiert haben,
‫diese Fehler natürlich nicht abfangen, oder?
‫Um zu testen, was
‫passiert, ändern wir unser mongodb-Passwort, okay?
‫Denn auf diese Weise
‫werden wir keine Verbindung zur Datenbank herstellen können, oder?
‫Und so sollten wir dann eine Art Fehler
‫bekommen, also gehen wir hier zu
‫unserer Serverdatei und speichern sie, um unseren Server neu
‫zu laden, erhöhen wir sie
‫hier, und tatsächlich haben wir hier eine unbehandelte Versprechensablehnung.
‫Und das ist eigentlich das Thema dieses Videos.
‫Eine nicht behandelte Versprechensablehnung bedeutet also, dass irgendwo in unserem
‫Code ein Versprechen vorhanden ist, das abgelehnt wurde.
‫Aber diese Ablehnung wurde nirgendwo behandelt, in Ordnung?
‫Und hier unten sehen Sie auch eine Veraltungswarnung, die
‫besagt, dass in Zukunft nicht behandelte
‫Ablehnungen einfach das laufende Knotenprogramm verlassen, was möglicherweise nicht
‫immer das ist, was Sie wollen, okay?
‫Lassen Sie uns also dieses Problem
‫beheben und diese unbehandelte Ablehnung von Versprechen loswerden.
‫In diesem einfachen Beispiel hier
‫wäre es eigentlich
‫ganz einfach, mit dieser Ablehnung umzugehen, oder?
‫Alles, was wir tun müssen, wäre,
‫zu diesem Codeabschnitt zu gelangen, in dem unsere Verbindung tatsächlich hergestellt
‫wird, und dann dort einen Catch-Handler hinzuzufügen, richtig?
‫Also ein bisschen so, und dann hier drin,
‫könnten wir mit dieser Ablehnung umgehen
‫und würden dann diesen Fehler nicht mehr bekommen.
‫Lass mich dir das nur schnell zeigen.
‫Versuchen Sie es also noch einmal.
‫Und so erhalten Sie jetzt einen Fehler, der natürlich
‫das Ergebnis dieses Protokolls hier
‫ist, aber natürlich erhalten wir keine unbehandelte
‫Versprechensablehnung, weil wir es hier tatsächlich behandelt haben, in Ordnung?
‫Das würde natürlich funktionieren, aber ich möchte Ihnen wirklich zeigen, wie
‫Sie global mit nicht bearbeiteten abgelehnten Zusagen umgehen, denn
‫bei einer größeren Bewerbung kann es etwas schwieriger
‫werden, immer den Überblick über alle Zusagen zu behalten, die
‫bei einigen abgelehnt werden könnten Punkt, okay?
‫Und so kann es sein, dass Sie irgendwann
‫irgendwo eine unbehandelte Ablehnung von Versprechen haben und lassen Sie mich Ihnen
‫zeigen, wie Sie damit im Grunde genommen global umgehen können.
‫Lassen Sie uns jetzt lernen, wie man mit unbehandelten Ablehnungen umgeht, und
‫das werden wir hier tun.
‫Erinnern Sie sich also daran, wie wir in einem
‫der ersten Abschnitte des Kurses über Ereignisse
‫und Ereignishörer gesprochen haben, richtig?
‫Und jetzt ist es an der Zeit, dieses Wissen tatsächlich zu nutzen.
‫Jedes Mal, wenn es irgendwo in
‫unserer Anwendung eine unbehandelte Ablehnung gibt, gibt
‫das Prozessobjekt ein Objekt namens unbehandelte Ablehnung
‫aus, und wir können dieses Ereignis einfach so abonnieren.
‫Also verarbeiten. an, merken Sie sich und
‫dann den Namen des Ereignisses, unbehandelte Zurückweisung, und
‫dann erhält die
‫Rückruffunktion hier einen Fehler, und so können wir
‫den Fehler tatsächlich in der Konsole protokollieren.
‫Verwenden wir also err. Name und Fehler. Botschaft.
‫Dies sind also einige Standardeinstellungen, die wir
‫für alle Fehler in node. js, in Ordnung?
‫Okay, und nach dem Speichern bekommen wir schon
‫hier unten den Namen des Fehlers und auch die Fehlermeldung.
‫Also schlechte Authentifizierung, was natürlich daran liegt, dass wir das
‫falsche Passwort haben.
‫Und so wird die unbehandelte Ablehnung des Versprechens
‫jetzt tatsächlich behandelt.
‫Und natürlich wird nicht nur die von dieser fehlgeschlagenen Verbindung,
‫sondern auch jede andere Ablehnung des Versprechens behandelt,
‫die wir möglicherweise nicht irgendwo in der Anwendung finden, hier in diesem
‫Finale, nennen wir es Sicherheitsnetz, in Ordnung?
‫Wir müssen also immer davon ausgehen, dass wir
‫als Programmierer Fehler machen.
‫Es ist also immer am besten, einen solchen zentralen Ort zu haben,
‫an dem alle Ablehnungen von
‫Versprechen wie ein letztes Sicherheitsnetz behandelt werden, in Ordnung?
‫Wenn wir nun wirklich ein Problem
‫mit der Datenbankverbindung haben, wie in diesem Beispiel,
‫dann wird unsere Anwendung überhaupt nicht funktionieren.
‫Also alles, was wir hier
‫wirklich tun können, ist, unsere Anwendung zu schließen, in Ordnung?
‫Um die Anwendung herunterzufahren, verwenden wir also process. Ausfahrt.
‫Und das haben wir tatsächlich schon
‫früher in diesem Skript verwendet, in dem wir
‫alle Daten aus der JSON-Datei in die Datenbank importiert haben, erinnerst du dich?
‫Also verarbeiten. exit und dann hier
‫rein, wir können tatsächlich einen Code übergeben.
‫Und der Code Null steht
‫für Erfolg und Eins für unabgefangene Ausnahme.
‫Und das wird hier normalerweise verwendet, in Ordnung?
‫Normalerweise werden Sie es also immer so sehen.
‫Und fügen wir hier einfach wie ein Protokoll hinzu, Konsole. log unhandler die
‫Ablehnung, etwa
‫so.
‫Ihr seht also, das gefällt mir sehr, dieses hier.
‫Lassen Sie dies einfach Knoten sein ...
‫Nicht wirklich Benutzer, aber
‫unser Protokoll, das wir schließen, in Ordnung?
‫Und jetzt sehen Sie, dass die App tatsächlich abgestürzt ist.
‫Und das liegt an diesem Prozess. geh hier raus, in Ordnung?
‫Nun, es gibt nur ein Problem mit der Art
‫und Weise, wie wir es
‫gerade implementiert haben, und das ist, dass wir es hier so
‫implementieren, dass es einfach verarbeitet wird. exit ist eine
‫sehr abrupte Möglichkeit, das Programm zu beenden, da
‫dies alle derzeit noch laufenden oder anstehenden Anfragen
‫sofort abbricht und daher möglicherweise keine gute Idee ist, okay?
‫Normalerweise fahren wir also ordnungsgemäß herunter, wo
‫wir zuerst den Server schließen
‫und erst dann die Anwendung herunterfahren, okay?
‫Also lass uns...
‫Bevor wir das tun, müssen wir
‫den Server hier grundsätzlich in einer Variablen speichern, okay?
‫Und so das Ergebnis des Aufrufens der App. listen ist ein Server und
‫auf diesem Server können wir jetzt Server sagen. close was, wie der Name
‫schon sagt, den Server schließt und
‫dann, nachdem das erledigt
‫ist, diese Callback-Funktion ausführt, die wir ihm übergeben haben, also
‫nur hier,
‫wo wir dann den Server herunterfahren, okay?
‫Und so tun Sie dies, indem Sie server. close, wir geben
‫dem Server im Grunde Zeit, alle Anfragen zu beenden, die
‫zu diesem Zeitpunkt noch ausstehen oder bearbeitet werden, und
‫erst danach wird der Server dann
‫im Grunde beendet, in Ordnung?
‫Wenn wir ihm also
‫einen Safe geben, wird es nicht genau gleich
‫aussehen, denn (lacht) ja, wir sind wie die einzigen,
‫die wirklich auf diese Anwendung zugreifen, aber in der
‫realen Welt sollten wir es immer so machen, okay ?
‫Und natürlich ist es nicht wirklich
‫ideal, dass die Anwendung abgestürzt ist, oder?
‫Denn im Moment läuft die App natürlich
‫nicht, sie funktioniert überhaupt nicht, oder?
‫In einer Produktions-App auf einem Webserver haben wir normalerweise ein Tool,
‫das die Anwendung direkt nach dem
‫Absturz neu startet, oder auch einige der Plattformen, die
‫den Knoten hosten. js macht
‫das automatisch von selbst, okay?
‫Denn natürlich wollen wir die Bewerbung nicht
‫ewig so hängen lassen.
‫Das ist also auch nicht nützlich, in Ordnung?
‫Und so gehen Sie im
‫Grunde genommen mit unbehandelten, abgelehnten Versprechen um.
‫Im Grunde hören wir also wieder auf
‫dieses nicht behandelte Zurückweisungsereignis, das es uns dann
‫ermöglicht, alle Fehler zu
‫behandeln, die in asynchronem Code auftreten
‫und die zuvor nicht behandelt wurden.
‫Aber jetzt könnten Sie sich fragen, was ist mit dem synchronen Code?
‫Wo sollen wir das handhaben?
‫Und die Antwort darauf liegt, wie Sie sich vorstellen
‫können, im nächsten Video.