‫Lehrer: Alles klar!
‫Und jetzt, um diesen Abschnitt
‫abzuschließen, lernen wir, wie man nicht abgefangene Ausnahmen abfängt.
‫Aber was genau sind nicht erfasste Ausnahmen?
‫Nun, alle Fehler, oder nennen wir sie auch Bugs,
‫die in unserem synchronen Code
‫auftreten, aber nirgendwo behandelt werden, werden als nicht abgefangene Ausnahmen bezeichnet.
‫Und wie zuvor, so wie bei den unbehandelten Ablehnungen, haben wir
‫auch eine Möglichkeit, nicht abgefangene Ausnahmen zu behandeln.
‫Lassen Sie mich Ihnen also schnell
‫ein Beispiel für eine nicht abgefangene Ausnahme zeigen.
‫Also tun wir einfach so, als wollten
‫wir trösten. log etwas, das nicht existiert.
‫Und so erhalten wir sofort diesen Fehler hier, x ist nicht definiert,
‫und dann erhalten wir standardmäßig diesen gesamten Stack-Trace hier
‫auf der Konsole gedruckt.
‫Gut.
‫Und nun, um dies zu beheben, ist dies sehr ähnlich wie bei
‫den unbehandelten Ablehnungen.
‫Wir hören also wieder auf ein Ereignis,
‫dieses Mal heißt es uncaughtException.
‫Und natürlich muss es in Anführungszeichen stehen.
‫Und dann übergeben wir wie zuvor unsere Callback-Funktion.
‫Okay.
‫Und jetzt ist das, was wir hier tun, sehr ähnlich zu dem,
‫was wir hier gemacht haben.
‫Also wollen wir den Fehler auf die
‫Konsole sperren, damit er dann in den Logs auf unserem Server auftaucht, okay?
‫So geben Sie uns eine Möglichkeit, das Problem dann zu beheben.
‫Und dann wollen wir den Server ordnungsgemäß herunterfahren.
‫Also, nun, eigentlich möchte ich
‫hier den gesamten Fehler an die Konsole
‫ausgeben und nicht nur die Nachricht, okay?
‫Und ändern wir auch hier die Reihenfolge,
‫aber das war's.
‫Der Rest ist also gleich.
‫Und
‫hier ist es natürlich UNCUGHT EXCEPTION!
‫Jetzt könnte ich das hier in eine nette Funktion umwandeln,
‫aber belassen wir es einfach so, in Ordnung?
‫Okay, also lassen Sie uns das jetzt wiederholen.
‫Schauen wir uns also an, was wir hier haben.
‫Und tatsächlich sehen wir jetzt UNCUGHT EXCEPTION!
‫Herunterfahren.
‫Gut?
‫Und tatsächlich druckt dies wieder den gesamten Stack auf die
‫Konsole, aber das möchte ich nicht wirklich.
‫Ich mag das nicht.
‫Kommen wir also einfach zu dem zurück, was wir hier hatten.
‫Also irr. Name und dann Fehler. Botschaft.
‫Okay, und jetzt haben
‫wir den ReferenceError, dass x nicht definiert ist, okay?
‫Und lassen Sie uns das gleiche hier setzen.
‫Also genau wie früher.
‫Gut.
‫Und das ist
‫eigentlich alles, um unabgefangene Ausnahmen abzufangen.
‫Während hier in der unbehandelten Ablehnung das
‫Abstürzen der Anwendung wie hier optional ist, müssen
‫wir bei einer nicht abgefangenen Ausnahme
‫unsere Anwendung wirklich, wirklich abstürzen, denn nachdem eine nicht
‫abgefangene Ausnahme aufgetreten ist, befindet sich der gesamte
‫Knotenprozess in einem
‫Zustand - sogenannter unreiner Zustand, in Ordnung?
‫Um das zu beheben, muss der Prozess beendet und dann
‫neu gestartet werden, in Ordnung?
‫Und wieder, in
‫der Produktion sollten wir dann ein
‫Tool haben, das die Anwendung nach einem Absturz neu startet.
‫Und viele Hosting-Dienste tun dies bereits out of
‫the box, in Ordnung?
‫Also ganz automatisch, ohne dass wir
‫etwas tun müssen.
‫Jetzt in Node. js, es ist
‫nicht wirklich empfehlenswert, sich blind auf diese beiden Fehlerhandler zu verlassen,
‫die wir gerade hier implementiert haben, okay?
‫Idealerweise sollten Fehler also wirklich dort behandelt
‫werden, wo sie auftreten.
‫So sollten wir zum Beispiel beim Verbindungsproblem mit der Datenbank
‫natürlich dort einen Catch-Handler hinzufügen und
‫uns nicht einfach auf
‫den unbehandelten Zurückweisungs-Callback verlassen, den wir hier haben, okay?
‫Und manche Leute sagen sogar, dass wir diese überhaupt nicht verwenden sollten, aber dem
‫stimme ich nicht zu.
‫Ich denke, dass sie als Sicherheitsnetz, sagen wir,
‫sehr nützlich sein können und eine Rolle in unserer Anwendung spielen.
‫Eigentlich sollte dieser
‫Handler hier ganz oben in unserem Code stehen, okay?
‫Oder zumindest bevor irgendein anderer Code wirklich ausgeführt wird.
‫Denn beobachten Sie, was passiert, wenn ich diese Codezeile hier
‫vor diesen Handler schiebe.
‫Wenn ich es also zum Beispiel
‫hier platziere und dann speichere,
‫dann sehen Sie
‫tatsächlich, dass unser Handler diese Ausnahme nicht abfängt, also diesen Fehler hier, oder?
‫Und das liegt daran, dass wir
‫erst hier am Ende tatsächlich auf eine unaufgefangene Ausnahme lauschen.
‫Aber in diesem Fall hier tritt die nicht
‫abgefangene Ausnahme auf, bevor wir dieses Ereignis überhaupt hören.
‫Und deshalb haben wir keine Möglichkeit, es zu fangen, oder?
‫Also sollten wir es idealerweise hier ganz oben platzieren, bevor
‫anderer Code ausgeführt wird.
‫Vor allem die in unserer Bewerbung.
‫Also lassen Sie es uns hier richtig sagen.
‫Das Problem hier wird nun
‫sein, dass der Server zu diesem Zeitpunkt noch nicht definiert ist.
‫Aber das ist
‫kein Problem, denn eigentlich brauchen wir
‫den Server hier gar nicht, oder?
‫Und das liegt
‫daran, dass diese Fehler, also
‫diese nicht abgefangenen Ausnahmen, nicht asynchron auftreten.
‫Sie werden also nichts
‫mit dem Server zu tun haben.
‫Das brauchen wir hier also gar nicht.
‫Wir können es einfach
‫hier speichern und haben es jetzt, bevor wir unsere
‫Hauptanwendung tatsächlich benötigen.
‫Wenn wir also jetzt einen
‫Fehler haben, versuchen wir es zuerst
‫hier, damit Sie
‫sehen, dass wir ihn jetzt wieder in unserem Fehlerhandler abfangen.
‫Aber wenn wir jetzt diesen Code hätten, zum Beispiel in der App. js, sagen wir, es spielt
‫keine Rolle, sagen wir einfach, es ist hier,
‫und wenn wir
‫das jetzt ausführen, sehen Sie, dass wir
‫immer noch diese Ausnahme in
‫unserem Fehlerhandler abfangen, was vorher nicht der Fall war.
‫Gut?
‫Und jetzt nur für
‫ein Experiment, was denken Sie, wenn wir diesen
‫Code direkt hier in diese Middleware-Funktion einfügen?
‫Was wird Ihrer Meinung nach
‫passieren, wenn wir diese Datei jetzt speichern?
‫x ist also immer noch nirgendwo definiert, aber schauen wir
‫uns an, was passiert, wenn wir
‫diesen Code jetzt ausführen.
‫Und so haben wir jetzt eigentlich keinen Fehler mehr.
‫Oder wir tun es
‫tatsächlich, aber das liegt nur an unserer unbehandelten Ablehnung,
‫die daran liegt, dass unser
‫Passwort hier immer noch falsch ist.
‫Wenn wir das also speichern und jetzt erneut speichern,
‫sollten Sie überhaupt keinen Fehler sehen.
‫Und das tun wir tatsächlich nicht.
‫Und warum ist das?
‫Nun, das liegt daran, dass diese Middleware-Funktion hier
‫natürlich nur aufgerufen
‫wird, sobald es tatsächlich eine Anfrage gibt, oder?
‫Sehen wir uns an, was passiert, wenn wir eine Anfrage stellen.
‫Lassen Sie uns also eine Get All Tours-Anfrage stellen.
‫Und warten wir darauf.
‫Und hier bekommen wir ein "Etwas ist sehr schief gelaufen! "Fehlermeldung beim
‫500, und das liegt auch
‫daran, dass wir noch
‫im Produktionsmodus sind, okay?
‫Aber wie auch immer, wenn Sie diese Nachricht hier erhalten, denken
‫Sie daran, dass hier ein nicht betriebsbereiter Fehler vorliegt.
‫Im Grunde also ein Fehler, den wir nicht selbst erstellt haben.
‫Und so, genau das geben wir jetzt
‫hier in unseren errorController ein, wir gehen gleich hier, oder?
‫Also in diesen else-Zweig hier in der Funktion sendErrorProd.
‫Und tatsächlich siehst du
‫den Fehler auch hier unten in der Konsole, okay?
‫Und das passiert, wenn
‫ein Fehler in einer Express-Middleware auftritt, richtig?
‫Wenn also ein Fehler
‫auftritt, geht Express automatisch mit diesem Fehler
‫zur Fehlerbehandlungs-Middleware, okay?
‫Wenn wir hier
‫in einer unserer Middleware-Funktionen einen
‫Fehler erhalten, wird dieser daher sofort in diesen Handler geleitet, okay?
‫Und da wir
‫in der Produktion sind, wird es
‫diesen Block hier eingeben, aber da es
‫kein CastError ist, und nicht dieser Fehler und
‫kein ValidationError, dann geben wir, sobald der Fehler tatsächlich
‫gesendet wird, genau hier diesen Block ein .
‫Und auch deshalb senden wir diesen generischen Fehler, in Ordnung?
‫Lassen Sie uns nun diesen Modus hier
‫tatsächlich verlassen und zu unserem normalen npm-Start zurückkehren.
‫Und so wird unser Fehler jetzt so gesendet, oder?
‫Senden Sie den Entwicklungsfehler, um uns alle Details
‫zu dem aufgetretenen Fehler mitzuteilen.
‫Und so erhalten wir jetzt tatsächlich ReferenceError: x ist nicht definiert.
‫Okay?
‫Also in App. js, Zeile 21.
‫Zeile 21 ist also dort, wo sie ist, aber lassen Sie
‫sie uns los.
‫Ich wollte es dir nur zeigen.
‫Okay?
‫Wie auch immer, damit schließen wir tatsächlich
‫unseren Abschnitt zur Fehlerbehandlung.
‫Und es könnte einen ganzen Kurs zur Fehlerbehandlung mit
‫Node und Express geben, denn es ist wirklich
‫ein wahnsinnig komplexes Thema.
‫Aber in diesem Abschnitt lernen Sie die Grundlagen,
‫die Sie wissen müssen, um wirklich mit
‫der Erstellung erstaunlicher Anwendungen zu beginnen.