‫Dozent: Hallo.
‫Lassen Sie uns nun einige nette Fehlerseiten für unsere Benutzer rendern.
‫Lassen Sie uns also zunächst einen Fehler erstellen.
‫Lassen Sie uns diese Tour hier eröffnen.
‫Nein, ich möchte nicht übersetzen.
‫Und jetzt fügen wir diesem Log hier einfach etwas hinzu, und
‫das wird dann natürlich nicht gefunden.
‫Richtig, und so sieht ein Fehler an dieser
‫Stelle aus.
‫Also einfach all dieses JSON
‫hier, so wie es in Postman aussehen würde.
‫Wir haben diese Art von Fehler hier schon einmal gesehen.
‫Also, lassen Sie uns das jetzt beheben.
‫Aber zuerst müssen wir diesen speziellen Fehler tatsächlich beheben.
‫Im Moment erhalten
‫wir also den Eigenschaftsnamen null in getTour nicht lesen können.
‫Okay.
‫Und das ist hier in unserem Views-Controller getTour.
‫Und hier drin haben wir also keine
‫Fehlerbehandlung für den Fall, dass es keine Tour gibt, oder?
‫Das haben wir also in all unseren anderen Routenhandlern, aber
‫in diesem haben wir es noch nicht.
‫Also fügen wir das hinzu.
‫Wenn es also keine Tour gibt, kehren Sie zurück und
‫gehen Sie mit einem neuen App-Fehler zur nächsten Middleware.
‫Und wahrscheinlich ist das noch nicht da.
‫Und nein, das ist es nicht.
‫Also konst.
‫AppError gleich.
‫In Ordung.
‫Fehler hier natürlich.
‫Und dann sagen wir,
‫es gibt keine Tour mit diesem Namen.
‫Und dann ist es ein 404 für nicht gefunden.
‫Okay?
‫Versuchen wir es also noch einmal.
‫Und so sollten wir jetzt einen viel schöneren Fehler bekommen.
‫Und tatsächlich bekommen wir einen.
‫Also 404.
‫Und denken Sie daran, dass es sich jetzt um einen Betriebsfehler handelt.
‫Also ein Fehler, von dem wir wissen, dass wir uns im Grunde genommen selbst erstellt haben.
‫Und das wird nach wie vor für
‫unsere Fehlerbehandlungsstrategie wichtig sein.
‫Reden wir also tatsächlich darüber.
‫Und hier sind wir fertig.
‫Und jetzt haben wir in
‫unserem Fehlercontroller zwei Funktionen, die Fehler an
‫den Client zurücksenden.
‫Also haben wir dieses hier für die
‫Entwicklung und dieses für die Produktion.
‫In der Produktion unterscheiden
‫wir dann zwischen Bedienungsfehlern und anderen unbekannten Fehlern.
‫Rechts?
‫Und das ist es, worüber wir gerade vorher gesprochen haben.
‫Bei den uns bekannten Fehlern
‫senden wir die eigentliche Fehlermeldung zurück, weil wir sicher
‫sein können, dass es sich nicht um
‫einen seltsam aussehenden
‫Fehler handelt, der irgendwo von Express oder
‫Note oder ähnlichem kommt.
‫Auf der anderen Seite, wenn es sich um einen unbekannten
‫Fehler handelt, wollen wir die Fehlerdetails nicht preisgeben.
‫Und nun werden wir in diesem Fall
‫mit der gerenderten Website tatsächlich dieselbe Strategie verwenden.
‫Jetzt füge
‫ich einfach jeder dieser Funktionen das
‫Rendering einer Fehlerseite hinzu.
‫Und im Grunde werde ich
‫testen, ob die URL mit Slash-API beginnt.
‫Und in diesem Fall senden wir diese Art von Fehler, richtig.
‫Aber wenn die URL nicht mit API beginnt, bedeutet dies,
‫dass wir eine Fehlerseite als gerenderte
‫Website rendern möchten, okay?
‫Also genau wie wir es in diesem Abschnitt getan haben.
‫Wie auch immer, lassen Sie uns das jetzt implementieren.
‫Und so können wir die ursprüngliche URL des Anfragepunkts verwenden.
‫Und wahrscheinlich haben wir das schon einmal benutzt.
‫In Ordung?
‫Original-URL ist also im Grunde die gesamte URL, aber nicht
‫mit dem Host.
‫So sieht es dann genau so aus wie die Route.
‫Und so wieder, wenn wir unsere
‫URL erreichen, dann beginnt diese Route mit der Slash-API.
‫Und jetzt können wir das testen.
‫Wir können also eine JavaScript-Funktion namens startsWith verwenden.
‫Also eine Funktion, die für Strings verfügbar ist.
‫Und dann testen Sie, ob es mit der Slash-API beginnt.
‫Rechts?
‫Und wenn ja, dann wollen wir dies tun.
‫Senden Sie den Fehler also einfach als JSON herunter.
‫Aber wenn nicht, dann wollen wir eigentlich einen Fehler rendern.
‫Es ist also immer noch res. Status.
‫Und auch zu statusCode.
‫Aber hier drin ist es eigentlich rendern.
‫Dann erhalten wir den Namen der Vorlage,
‫und wir werden diese Vorlage in einer Sekunde erstellen, aber
‫sie wird als Fehler bezeichnet.
‫Und dann sind die Daten, die wir dorthin
‫schicken wollen, vorerst nur der Titel.
‫Und ich werde noch einiges
‫hinzufügen, wenn die Vorlage tatsächlich fertig ist.
‫Also, etwas ist schief gelaufen, wird der Titel
‫dieser Fehlerseite sein.
‫In Ordung?
‫Oh, eigentlich haben wir
‫hier keinen Zugriff auf die Request-Variable.
‫Und seine Funktion.
‫Und so fügen wir das hinzu.
‫Anfrage hier.
‫Und auch hier werden wir es brauchen.
‫Dieses.
‫Und das fügen wir auch hier hinzu.
‫Also gleich hier.
‫Okay.
‫Jetzt müssen wir also tatsächlich diese Seite oder
‫diese Vorlage namens error erstellen.
‫Und dafür habe ich auch schon wieder eine einfache Vorlage.
‫Es befindet sich also in dev-data, templates und errorTemplate.
‫Okay?
‫Also kopieren wir das.
‫Und dann erstellen Sie eine Ansicht dafür.
‫Error. Mops.
‫Okay.
‫Hier haben wir also ein einfaches h2, das sagt, uh
‫oh, etwas ist schief gelaufen.
‫Dann (lacht) ein paar lustige Emojis.
‫Sie machen nicht wirklich Spaß.
‫Und dann wollen wir hier auch noch eine Nachricht weitergeben können.
‫In Ordung?
‫Fügen wir dies also gleich zu msg hinzu, nur eine Abkürzung für Nachricht.
‫In Ordung?
‫Und das ist es tatsächlich.
‫Schließen wir das und geben wir diese Nachricht weiter.
‫Damit ist dann msg gesetzt.
‫Und lass es uns wirklich auf Fehlerpunktnachricht einstellen.
‫Okay?
‫Und das machen wir hier, weil wir uns in der Entwicklung befinden.
‫Behalte das also im Hinterkopf.
‫Lassen Sie uns hier auch einige Kommentare hinzufügen.
‫API.
‫Stellen wir das hier.
‫Die gerenderte Website.
‫Also machen wir es wieder so, mit Fehlermeldung,
‫denn in der
‫Entwicklung spielt es keine Rolle, ob wir alle Fehlerdetails
‫an unsere Seite weitergeben, oder?
‫Denn niemand wird es wirklich sehen, denn ja, wir sind
‫in der Entwicklung.
‫Das sollte also jetzt funktionieren.
‫Alles, was wir jetzt tun müssen, ist diese Seite neu zu laden.
‫Aber jetzt stimmt hier etwas nicht.
‫Es heißt also, es wurden keine Daten gesendet.
‫Gehen wir also hierher zurück.
‫Naja als erstes Problem sehe ich
‫hier, dass ich den Statuscode haben soll und nicht nur den Status.
‫Das ist alles, um zu überprüfen, ob wir hier einen Fehler haben.
‫Oh ja.
‫Tatsächlich gibt es Fehler.
‫Es war also tatsächlich der ungültige Statuscode.
‫Hier sollte es also Code sein.
‫Lassen Sie uns das noch einmal speichern.
‫Erneut laden.
‫Und jetzt bekommen wir hier eine Fehlerseite.
‫Nun, es ist nicht wirklich formatiert.
‫Aber trotzdem hat es den Titel und, was noch
‫wichtiger ist, es hat diese Botschaft, die wir gerade weitergegeben haben.
‫Es gibt also keine Tour mit diesem Namen.
‫Und das kommt genau von unserem Views Controller.
‫Also gleich von hier.
‫Denken Sie also an die Logik, bei der wir hier einen Fehler
‫erstellen, der dann an unsere globale Fehler-
‫und Lint-Middleware weitergegeben wird.
‫Rechts?
‫Und das ist derjenige, der diese
‫Fehler aufnimmt und an den Client sendet.
‫In unserem Fall erhalten wir jetzt
‫diesen Fehler, weil wir hier in unserer Vorlage
‫noch etwas vergessen haben.
‫Was natürlich nur dazu dient, unser Haupttemplate zu erweitern.
‫Rechts?
‫Wir müssen also sagen, bis zur Basisvorlage erweitern.
‫Und dann erstellen Sie diesen Block wie immer hier.
‫Also Inhalt blockieren.
‫Und dann muss das alles drin sein.
‫Im Grunde machen
‫wir hier genau dasselbe wie bei allen anderen Vorlagen.
‫Im Grunde fügen Sie diesen
‫Inhalt hier in den Inhaltsblog in der Basisvorlage ein.
‫Wenn wir das also jetzt neu laden, dann sieht es endlich so aus, wie beabsichtigt.
‫In Ordung?
‫Und jetzt, wenn wir tatsächlich einen Fehler in unserem Code
‫hatten, und sagen wir noch einmal,
‫dass wir diese Fehlerbehandlung hier nicht haben, dann
‫wird natürlich der gesamte Fehler an den Client weitergegeben.
‫Daher kann der Eigenschaftsname null nicht gelesen werden.
‫Und natürlich möchten wir nicht, dass unsere
‫Website-Besucher solche Fehler bekommen, oder?
‫Niemand würde wirklich verstehen, was das bedeutet.
‫Und darum kümmern wir uns jetzt
‫in unserem Produktionsfehlerhandler.
‫Hier unten in unserem Fehlercontroller wenden
‫wir nun dieselbe Logik an, die wir hier haben.
‫Testen Sie also, ob wir derzeit mit der API umgehen oder nicht.
‫Und natürlich könnte es elegantere Möglichkeiten geben, dies
‫zu tun.
‫Sie könnten beispielsweise eine komplett separate
‫Middleware zur Fehlerbehandlung nur für die API und
‫eine für die gerenderte Website haben, oder?
‫Aber auch hier möchte ich es einfach etwas einfacher halten.
‫Okay?
‫Das ist in diesem Fall also wirklich mein Hauptziel.
‫In Ordung.
‫Lassen Sie uns all dies auswählen.
‫Ach, was ist da passiert?
‫Ach, los geht's.
‫Okay.
‫Das ist also für die API.
‫Und jetzt werden wir tatsächlich etwas ganz Ähnliches haben.
‫Dies ist also wieder für die gerenderte Website.
‫Nennen wir es hier B und hier A.
‫Also nur um es etwas besser zu trennen.
‫Also haben wir und dann B hier unten.
‫Wie auch immer, dies wird diesem hier ein wenig ähnlich sehen.
‫Wenn wir also einen Betriebsfehler haben, sollte die Fehlerseite
‫im Grunde
‫genauso aussehen wie hier zuvor.
‫Aber für den Fall, dass es sich um einen Programmierfehler
‫oder einen unbekannten Fehler handelt, wollen wir nicht die vollständige Nachricht,
‫sondern nur eine sehr allgemeine Nachricht.
‫Bitte versuchen Sie es später erneut.
‫In Ordung?
‫Sehen wir uns nun an, welche Art von Fehler wir hier bekommen.
‫Und anscheinend erhalten wir hier etwas, das
‫als einsames if-Statement bezeichnet wird.
‫Rechts.
‫Also ja, Lint möchte
‫nicht, dass wir nur ein if innerhalb eines else-Blocks haben.
‫Und ich stimme zu,
‫dass es keine schöne Programmierpraxis ist.
‫Lassen Sie uns das also in der Tat
‫beheben, indem wir das andere hier loswerden.
‫Sparen Sie.
‫Und dann ist dieser Fehler weg.
‫Aber jetzt müssen wir sicherstellen, dass dies
‫hier wirklich den Request-Response-Zyklus beendet.
‫Und so müssen wir auch hier und hier zurückkehren.
‫In Ordung.
‫Jetzt noch ein ESLint-Fehler, sonst unnötig nach einer Rückkehr.
‫Und das stimmt auch.
‫Und ich habe diese Regel
‫während des gesamten Kurses befolgt, weil ich es selbst
‫als Programmierpraxis mag.
‫Also, ja, lass uns das hier dann loswerden.
‫Ich glaube wirklich, und ich glaube es schon
‫lange, dass es ohne diese wenn-sons-Anweisungen viel schöner aussieht, sondern
‫nur mit einem wenn, wie hier hier, und dann
‫das else außerhalb davon mit einbezieht.
‫Okay, das haben wir jetzt hier.
‫Setzen wir hier auch A und B ein.
‫B.
‫Und tatsächlich, lassen Sie uns hier genau dasselbe tun.
‫Also zurück.
‫Gib auch diesen zurück.
‫Dann auch hier A und B.
‫Also für mich sieht das in der Tat sauberer aus.
‫Jetzt haben wir A hier und
‫A hier wieder, aber nun, egal an dieser Stelle.
‫In Ordung.
‫Also kehre hierher zurück.
‫Kehren Sie hierher zurück.
‫Und bevor es mich anschreit, lass uns das entfernen.
‫Und damit ist es wieder besser.
‫Also stell das hier raus.
‫Und das sollte es eigentlich sein.
‫In Ordung?
‫Lassen Sie uns
‫der Vollständigkeit halber auch diesen Kommentar hier kopieren.
‫Und dann nenne das hier wieder B.
‫In Ordung.
‫Perfekt.
‫Lassen Sie uns diesen hier auch tatsächlich
‫in die Entwicklungsfunktion kopieren.
‫Denn im Moment haben wir, sobald wir diesen
‫Fehler zurücksenden, wirklich keine Möglichkeit, den vollständigen Fehler zu sehen.
‫Okay, also, entfernen Sie es, um es sichtbarer zu machen.
‫Und das ist jetzt schön.
‫Okay.
‫Beenden wir es
‫jetzt hier, damit wir unsere Produktionsanwendung starten können.
‫Also im Grunde läuft es jetzt in der Produktion.
‫Und wir haben ein Skript
‫dafür, das sich npm run start production nennt.
‫Okay?
‫Wenn wir das also jetzt testen, sollten
‫wir diese Zeichenfolge hier nicht mehr sehen, erinnerst du dich?
‫Denn an dieser Stelle haben wir keine
‫Fehlerbehandlung für einen solchen ungültigen Tournamen.
‫Okay?
‫Rechts?
‫Da wir in
‫der Produktion sind und es sich nicht um
‫einen Betriebsfehler handelt, wollen wir dies nicht sehen.
‫Und das haben wir gerade vorher codiert.
‫Dies ist in der Tat die allgemeinere Fehlermeldung.
‫Rechts?
‫Aber wenn wir es dann hier im Views-Controller zurücksetzen, also
‫wenn wir diese Fehlerbehandlung zurücksetzen,
‫dann natürlich, da dies hier jetzt
‫ein Betriebsfehler ist, dann erhalten wir natürlich
‫diesen Fehlerstring.
‫Weil es immer schön
‫ist, dem Benutzer eine freundliche Nachricht zu zeigen.
‫Aber wie Sie gesehen haben, ist das tatsächlich nicht passiert.
‫Warum also?
‫Nun, wir sind im Produktionsfehler.
‫Wir befinden uns auf der gerenderten Website.
‫Und tatsächlich haben wir einen Bedienungsfehler.
‫Und so ...
‫Wir haben das vor Ort.
‫Und so sollte es tatsächlich so funktionieren, wie wir es erwartet haben.
‫Nun, versuchen wir einfach, die Fehlerpunktnachricht in der Konsole
‫zu loggen, nur um
‫zu sehen, ob wir sie zu diesem Zeitpunkt tatsächlich erhalten haben.
‫In Ordung.
‫Lade diesen Kerl neu.
‫Und damit liegt der Fehler vor.
‫Aber trotzdem ist das sehr seltsam.
‫Damit ist ja der gesamte Fehler protokolliert.
‫Sehr eigenartig.
‫Denn aus irgendeinem Grund ist die Nachricht auch nicht da.
‫Lassen Sie es uns also noch einmal in der Entwicklung ausführen.
‫Also npm starten.
‫In Ordung.
‫Und hier erhält es aus irgendeinem Grund Zugriff auf diese Nachricht.
‫Das bedeutet, dass wir diese Nachricht in
‫unserem Views-Controller tatsächlich richtig gesetzt haben.
‫Führen Sie es erneut in der Produktion aus.
‫Das ist also die Art von Sachen, die wir nicht mögen, oder?
‫Werfen wir also einen Blick darauf, wo unser
‫Produktionsfehler tatsächlich entsteht.
‫Und das ist hier.
‫Dieses Fehlerobjekt, das wir hier in der Produktion verwenden,
‫ist also eine Kopie dieses Fehlers, richtig?
‫Also der, der in diese Middleware kommt.
‫Schauen wir uns also beide in der Konsole
‫an.
‫Also Fehlerpunktmeldung.
‫Und dann auch Fehlerpunktmeldung.
‫Also mach das nochmal.
‫Okay.
‫Wir sehen also diesen
‫Fehler, also der, der direkt in unsere Middleware-Funktion
‫eingeht, hat tatsächlich die Meldung.
‫Aber das, was wir kopieren, also Fehler, aus
‫irgendeinem Grund nicht.
‫Und dieser Trick, den wir hier
‫machen, kopiert aus irgendeinem Grund die Nachricht nicht,
‫in Ordnung?
‫Also lassen Sie uns das schnell beheben.
‫Und nehmen wir an, dass die Fehlerpunktnachricht gleich der Fehlerpunktnachricht ist.
‫In Ordung?
‫Und damit sollte es dann hoffentlich behoben sein.
‫Ah, in Ordnung.
‫Auf geht's.
‫Rechts.
‫Jetzt sehen Sie, dass sie tatsächlich gleich sind.
‫Und das war das Problem.
‫In Ordung?
‫Ohne dies würden
‫also eigentlich alle Fehler nicht richtig funktionieren.
‫Also wenn wir das hier rausstellen
‫und zum Beispiel versuchen einzuloggen, so admin@natours. io.
‫Sie sehen also, auch hier erhalten wir einen undefinierten Fehler.
‫In Ordung.
‫Dies liegt wiederum daran, dass wir uns
‫in der Produktion befinden und unser Fehlerobjekt die Nachricht nicht korrekt kopiert hat.
‫Ich bin mir nicht sicher, warum ich das nicht
‫mitbekommen habe, als wir es tatsächlich implementiert haben.
‫Aber vielleicht habe ich es nicht gründlich genug getestet.
‫Okay?
‫Und egal, wenn wir das
‫jetzt versuchen, bekommen wir jetzt die richtige Fehlermeldung, die
‫wir erwarten.
‫In Ordung.
‫Groß.
‫Das ist also gelöst.
‫Und damit ist dieses Video eigentlich abgeschlossen.
‫Zusammenfassend lässt
‫sich sagen, dass wir jetzt
‫eine Fehlerbehandlungsstrategie haben, die wie bisher für die Entwicklung und auch
‫für die Produktion funktioniert.
‫Und dann haben wir in jedem von ihnen im Grunde zwei Filialen.
‫Man schickt die Fehlermeldung für die API, das
‫ist genau das, was wir vorher
‫hatten, und dann haben wir jetzt auch eine Art Handler
‫für die gerenderte Website.
‫In diesem Fall rendern wir unsere Fehlervorlage.
‫In der Produktion unterscheiden wir dann
‫auch noch zwischen gerenderter Website und API.
‫Und dann unterscheiden
‫wir auch innerhalb jedes dieser Zweige
‫nach wie vor zwischen
‫den Bedienungsfehlern und den unbekannten Fehlern.
‫Also betriebsbereit und unbekannt.
‫Und dann innen gerendert, auch betriebsbereit und unbekannt.
‫Wenn wir also für die
‫gerenderte Website einen Betriebsfehler haben, also einen
‫vertrauenswürdigen, senden wir unsere vertrauenswürdige Fehlermeldung.
‫Wenn wir dem Fehler jedoch nicht
‫vertrauen, also wenn wir
‫ihn nicht kennen, senden wir diese generische Nachricht einfach an den Benutzer zurück.
‫So großartig.
‫Lassen Sie uns das hier beenden und zurück zur
‫Entwicklung gehen und diesen Vortrag abschließen.
‫Also bis zum nächsten.