1 00:00:00,860 --> 00:00:03,680 ‫Kursleiter: Willkommen zurück, bevor wir uns nun 2 00:00:03,680 --> 00:00:06,820 ‫eingehend mit der eigentlichen Fehlerbehandlung befassen, schreiben wir 3 00:00:06,820 --> 00:00:09,430 ‫zunächst einen Handler für undefinierte Routen. 4 00:00:09,430 --> 00:00:12,250 ‫Also im Grunde für Routen, denen wir noch keinen 5 00:00:12,250 --> 00:00:13,403 ‫Handler zugewiesen haben. 6 00:00:14,800 --> 00:00:17,820 ‫Und zuerst müssen wir hier unsere Anwendung starten, 7 00:00:17,820 --> 00:00:21,053 ‫die wir nach der letzten Debug-Sitzung nicht beendet haben. 8 00:00:21,950 --> 00:00:23,363 ‫Also MPM starten. 9 00:00:25,260 --> 00:00:28,290 ‫Warten wir also auf eine Datenbankverbindung. 10 00:00:28,290 --> 00:00:33,290 ‫Hier ist es, also gehen wir jetzt zum Postman hier und versuchen, die Route 11 00:00:33,640 --> 00:00:36,810 ‫zu treffen, die wir noch nicht definiert haben. 12 00:00:36,810 --> 00:00:39,793 ‫Also kopiere ich einfach diese URL 13 00:00:41,892 --> 00:00:44,260 ‫hierher, in Ordnung, und sagen 14 00:00:44,260 --> 00:00:46,410 ‫wir zum Beispiel, dass 15 00:00:48,240 --> 00:00:49,490 ‫wir 16 00:00:49,490 --> 00:00:53,223 ‫anstelle von apiV1-Touren nur api/tours sagen würden. 17 00:00:54,140 --> 00:00:58,400 ‫Okay, in diesem Fall würden wir dieses HTML-Ergebnis 18 00:00:58,400 --> 00:01:01,470 ‫erhalten, in Ordnung, also sendet 19 00:01:01,470 --> 00:01:05,380 ‫Express automatisch diesen HTML-Code hierher, zusammen mit 20 00:01:05,380 --> 00:01:08,700 ‫einem 404 Not Found-Fehlercode, falls es 21 00:01:08,700 --> 00:01:12,900 ‫keinen Handler für die angeforderte Route gibt, okay. 22 00:01:12,900 --> 00:01:16,483 ‫Oder wir könnten hier zum Beispiel Tour auch einfach falsch schreiben. 23 00:01:17,640 --> 00:01:19,850 ‫In diesem Fall würden wir zum Beispiel 24 00:01:19,850 --> 00:01:21,840 ‫immer noch den gleichen Fehler erhalten. 25 00:01:21,840 --> 00:01:25,210 ‫Jetzt gibt es auch noch eine andere 26 00:01:25,210 --> 00:01:29,580 ‫Situation, wenn wir hier nach Touren etwas anderes angeben, 27 00:01:29,580 --> 00:01:31,800 ‫sagen wir einfach so. 28 00:01:31,800 --> 00:01:34,790 ‫Schauen wir uns also den Fehler an, den wir 29 00:01:34,790 --> 00:01:38,470 ‫erhalten, und jetzt erhalten wir, dass die Umwandlung in die Objekt-ID fehlgeschlagen ist. 30 00:01:38,470 --> 00:01:40,560 ‫Und das liegt daran, dass 31 00:01:40,560 --> 00:01:45,390 ‫wir hier nach der Tour eine Route haben, die einen ID-Parameter akzeptiert, richtig. 32 00:01:45,390 --> 00:01:48,770 ‫Und so versucht MongoDB im Grunde, ein Dokument 33 00:01:48,770 --> 00:01:53,180 ‫mit dieser ID zu finden, kann es aber nicht in 34 00:01:53,180 --> 00:01:55,160 ‫eine gültige MongoDB-Objekt-ID konvertieren. 35 00:01:55,160 --> 00:01:58,810 ‫Das ist also wieder eine andere Situation, lassen Sie uns einfach 36 00:01:59,820 --> 00:02:02,930 ‫weiter mit dieser arbeiten, also wieder, wo wir diesen 37 00:02:02,930 --> 00:02:05,550 ‫Fehler erhalten, aber in diesem HTML-Formular. 38 00:02:05,550 --> 00:02:08,330 ‫Da wir hier eine API erstellen, 39 00:02:08,330 --> 00:02:12,070 ‫macht es nicht viel Sinn, HTML zurückzusenden, richtig, also beheben 40 00:02:12,070 --> 00:02:15,400 ‫wir das jetzt und erstellen im Grunde eine Handle-Funktion 41 00:02:15,400 --> 00:02:19,270 ‫für alle Routen, die nicht von unseren Routern zwischengespeichert werden. 42 00:02:19,270 --> 00:02:22,610 ‫Okay, also kehren wir hier zu unserer Anwendung zurück und 43 00:02:22,610 --> 00:02:25,540 ‫öffnen die App. js. 44 00:02:25,540 --> 00:02:27,950 ‫Okay, das ist im Grunde 45 00:02:27,950 --> 00:02:30,180 ‫die Definition unserer Express-Anwendung. 46 00:02:30,180 --> 00:02:32,530 ‫Bevor wir etwas anderes tun, wollen wir 47 00:02:32,530 --> 00:02:35,190 ‫diese Middleware hier wirklich loswerden, die wir 48 00:02:35,190 --> 00:02:36,700 ‫nicht mehr brauchen. 49 00:02:36,700 --> 00:02:39,360 ‫Wir haben dies hier nur verwendet, um 50 00:02:39,360 --> 00:02:43,160 ‫das Konzept der Middleware zu demonstrieren, und brauchen das an 51 00:02:43,160 --> 00:02:45,080 ‫dieser Stelle nicht mehr. 52 00:02:45,080 --> 00:02:47,980 ‫Nun gut, wie implementieren wir einen 53 00:02:47,980 --> 00:02:51,410 ‫Route-Handler für eine Route, die von keinem unserer 54 00:02:51,410 --> 00:02:53,380 ‫anderen Route-Handler zwischengespeichert wurde? 55 00:02:53,380 --> 00:02:56,160 ‫Denken Sie also daran, dass alle diese Middleware-Funktionen 56 00:02:56,160 --> 00:02:59,770 ‫in der Reihenfolge ausgeführt werden, in der sie sich im Code befinden. 57 00:02:59,770 --> 00:03:02,930 ‫Die Idee ist also, dass, wenn wir eine Anfrage 58 00:03:02,930 --> 00:03:06,210 ‫haben, die es bis zu diesem Punkt unseres Codes 59 00:03:06,210 --> 00:03:08,760 ‫schafft, dies bedeutet, dass weder der 60 00:03:08,760 --> 00:03:12,860 ‫tourRouter noch der userRouter in der Lage waren, sie zwischenzuspeichern, okay. 61 00:03:12,860 --> 00:03:16,590 ‫Wenn wir also hier nach diesen Routern eine Middleware hinzufügen, wird 62 00:03:16,590 --> 00:03:20,060 ‫sie nur dann wieder erreicht, wenn sie von keinem 63 00:03:20,060 --> 00:03:22,470 ‫unserer anderen Router bearbeitet wird, okay. 64 00:03:22,470 --> 00:03:25,610 ‫Also lassen Sie uns das tun und dann wirklich verstehen, wie es 65 00:03:25,610 --> 00:03:27,550 ‫funktioniert, nachdem es bereits implementiert wurde. 66 00:03:27,550 --> 00:03:29,600 ‫Also implementieren wir einen Route-Handler 67 00:03:29,600 --> 00:03:30,923 ‫und sagen app. 68 00:03:32,450 --> 00:03:34,540 ‫und nun die HTTP-Methode, für die 69 00:03:34,540 --> 00:03:36,380 ‫wir die Route angeben möchten. 70 00:03:36,380 --> 00:03:40,630 ‫Jetzt könnten wir get here right verwenden, also genau wie 71 00:03:40,630 --> 00:03:43,410 ‫zuvor, aber was ist dann mit Post-Requests, 72 00:03:43,410 --> 00:03:45,030 ‫Lösch- oder Patch-Requests? 73 00:03:45,030 --> 00:03:47,730 ‫Sie müssten dann auch Handler für diese schreiben, 74 00:03:47,730 --> 00:03:50,190 ‫und das wollen wir nicht, wir wollen 75 00:03:50,190 --> 00:03:54,270 ‫einfach alle Routen, also alle URLs, für alle Verben hier in 76 00:03:54,270 --> 00:03:56,707 ‫diesem einen Handler verarbeiten, okay. 77 00:03:56,707 --> 00:03:59,710 ‫Und so können wir in Express die App verwenden. alle. 78 00:03:59,710 --> 00:04:02,460 ‫Und das wird dann für alle Verben 79 00:04:02,460 --> 00:04:05,430 ‫ausgeführt, also für die gesamte HTTP-Methode, in Ordnung. 80 00:04:05,430 --> 00:04:08,270 ‫Als nächstes geben wir die URL an, und 81 00:04:08,270 --> 00:04:10,920 ‫da wir hier alle URLs behandeln wollen, 82 00:04:10,920 --> 00:04:13,950 ‫die nicht behandelt wurden, können wir hier den Stern 83 00:04:13,950 --> 00:04:17,320 ‫verwenden, der für alles steht, gut, und der Rest ist 84 00:04:17,320 --> 00:04:19,920 ‫dann nur eine normale Middleware-Funktion , So 85 00:04:19,920 --> 00:04:21,183 ‫wie vorher. 86 00:04:23,980 --> 00:04:24,893 ‫Also 87 00:04:26,210 --> 00:04:27,883 ‫Anfrage, Antwort und weiter. 88 00:04:29,270 --> 00:04:32,290 ‫Okay, und was wollen wir hier machen? 89 00:04:32,290 --> 00:04:34,700 ‫Nun, wir möchten einfach eine Antwort 90 00:04:34,700 --> 00:04:38,653 ‫im JSON-Format zurücksenden, also nicht im HTML, das wir gerade haben. 91 00:04:40,100 --> 00:04:41,573 ‫Also res. status, 92 00:04:43,100 --> 00:04:46,110 ‫und hier setzen wir einen 404, also Not Found 93 00:04:48,220 --> 00:04:52,190 ‫und dann eine JSON-Antwort, also genau wie die übliche, bei der 94 00:04:52,190 --> 00:04:54,343 ‫wir den Status auf fehlschlagen setzen. 95 00:04:57,090 --> 00:05:01,153 ‫Also nur eine normale angrenzende formatierte Antwort. 96 00:05:03,590 --> 00:05:05,980 ‫Und dann eine Art Nachricht hier, und tatsächlich lassen 97 00:05:05,980 --> 00:05:07,580 ‫Sie uns hier einen Vorlagenstring 98 00:05:07,580 --> 00:05:09,790 ‫erstellen, weil ich dort eine Variable einfügen möchte. 99 00:05:09,790 --> 00:05:11,370 ‫Kann also nicht 100 00:05:11,370 --> 00:05:12,203 ‫finden. 101 00:05:13,380 --> 00:05:16,650 ‫Und dann können wir req verwenden. originalUrl okay, das ist 102 00:05:18,220 --> 00:05:21,900 ‫also eine Eigenschaft, die wir auf der Anfrage haben, 103 00:05:21,900 --> 00:05:26,233 ‫die, wie der Name schon sagt, die angeforderte URL ist, in 104 00:05:27,300 --> 00:05:28,270 ‫Ordnung. 105 00:05:28,270 --> 00:05:30,610 ‫Diese neue Antwort, die wir jetzt 106 00:05:30,610 --> 00:05:33,230 ‫zurücksenden, ist also viel besser als der 107 00:05:33,230 --> 00:05:37,163 ‫HTML-Code, den wir zuvor erhalten haben, also testen wir das jetzt. 108 00:05:40,440 --> 00:05:44,020 ‫Und tatsächlich bekommen wir jetzt hier eine JSON-Fehlermeldung zurück. 109 00:05:44,020 --> 00:05:47,970 ‫Hier erhalten wir also auch die angeforderte URL, und 110 00:05:47,970 --> 00:05:50,586 ‫zwar diejenige, auf die wir 111 00:05:50,586 --> 00:05:54,760 ‫versucht haben zuzugreifen, aber sie ist nicht verfügbar, gut, toll. 112 00:05:54,760 --> 00:05:57,240 ‫Nun nochmal, warum hat das funktioniert? 113 00:05:57,240 --> 00:06:01,200 ‫Die Idee ist also wieder, dass, wenn wir diesen Punkt 114 00:06:01,200 --> 00:06:04,120 ‫hier erreichen können, dies bedeutet, dass der Anfrage-Antwort-Zyklus 115 00:06:04,120 --> 00:06:06,281 ‫zu diesem Zeitpunkt in 116 00:06:06,281 --> 00:06:09,100 ‫unserem Code noch nicht abgeschlossen war, richtig. 117 00:06:09,100 --> 00:06:11,780 ‫Denken Sie daran, dass Middleware dem Middleware-Stack in der 118 00:06:11,780 --> 00:06:14,040 ‫Reihenfolge hinzugefügt wird, in der sie hier 119 00:06:14,040 --> 00:06:16,010 ‫in unserem Code definiert ist. 120 00:06:16,010 --> 00:06:18,810 ‫Im Grunde läuft dieser Code hier zuerst, 121 00:06:18,810 --> 00:06:21,840 ‫und wenn die Route hier in unserem tourRouter 122 00:06:21,840 --> 00:06:25,230 ‫abgeglichen würde, würde unsere Anfrage diesen Code nie erreichen 123 00:06:25,230 --> 00:06:27,660 ‫und dann würde dies nicht ausgeführt. 124 00:06:27,660 --> 00:06:30,050 ‫Und so sollte dies im Grunde der letzte 125 00:06:30,050 --> 00:06:32,560 ‫Teil nach all unseren anderen Routen sein, in Ordnung. 126 00:06:32,560 --> 00:06:35,240 ‫Und wenn ich das nur 127 00:06:35,240 --> 00:06:38,140 ‫zum Ausprobieren wäre, schreibe das jetzt ganz 128 00:06:39,230 --> 00:06:43,260 ‫oben in unsere Bewerbung, dann wirst du sehen, dass 129 00:06:43,260 --> 00:06:47,750 ‫wir, egal welche Anfrage wir machen werden, immer dieselbe Antwort erhalten. 130 00:06:47,750 --> 00:06:49,653 ‫Gut, also testen 131 00:06:51,550 --> 00:06:54,600 ‫wir das, und tatsächlich erhalten wir jetzt eine 132 00:06:54,600 --> 00:06:56,600 ‫JS-Fehlermeldung, und das liegt daran, 133 00:06:56,600 --> 00:06:59,850 ‫dass jetzt alle Anfragen diesen Routenhandler hier erreichen, und 134 00:06:59,850 --> 00:07:04,290 ‫es wird tatsächlich abgeglichen, weil es eine GET-Anfrage ist, die Teil aller 135 00:07:04,290 --> 00:07:08,060 ‫Verben ist, richtig, und dann alle Routen, also alle URLs 136 00:07:08,060 --> 00:07:10,760 ‫werden hier zwischengespeichert, und natürlich verarbeitet es 137 00:07:10,760 --> 00:07:13,920 ‫diese URL, die wir gerade hier gemacht haben. 138 00:07:13,920 --> 00:07:17,333 ‫Und das gleiche natürlich auch, zum Beispiel für eine Löschtour. 139 00:07:18,330 --> 00:07:20,590 ‫Also würde das gleiche passieren, wir würden 140 00:07:20,590 --> 00:07:22,573 ‫immer die gleiche Antwort bekommen, 141 00:07:23,740 --> 00:07:24,573 ‫in Ordnung. 142 00:07:25,430 --> 00:07:28,500 ‫Also legen wir es natürlich zurück, 143 00:07:28,500 --> 00:07:33,183 ‫aber das war nur, um zu zeigen, wie und warum 144 00:07:34,100 --> 00:07:35,670 ‫das funktioniert. 145 00:07:35,670 --> 00:07:38,890 ‫Großartig, also ist dies ein wichtiger Teil, um unsere API 146 00:07:38,890 --> 00:07:42,150 ‫ein wenig benutzerfreundlicher zu machen, aber als nächstes wollen wir 147 00:07:42,150 --> 00:07:44,873 ‫uns nun mit der echten Fehlerbehandlung vertraut machen.