1 00:00:01,150 --> 00:00:03,353 ‫Jonas: In diesem Video 2 00:00:03,353 --> 00:00:06,390 ‫implementieren wir eine Logik, um verschiedene Fehlermeldungen 3 00:00:06,390 --> 00:00:09,173 ‫für die Entwicklungs- und Produktionsumgebung zu senden. 4 00:00:10,810 --> 00:00:14,490 ‫Im Moment senden wir hier im Grunde die gleiche Antwortnachricht an 5 00:00:14,490 --> 00:00:17,389 ‫alle, egal ob wir uns in der Entwicklung oder 6 00:00:17,389 --> 00:00:18,920 ‫in der Produktion befinden. 7 00:00:18,920 --> 00:00:21,690 ‫Aber die Idee ist, dass wir in der Produktion so 8 00:00:21,690 --> 00:00:23,810 ‫wenig Informationen wie möglich über unsere Fehler 9 00:00:23,810 --> 00:00:25,583 ‫an den Kunden weitergeben wollen. 10 00:00:26,420 --> 00:00:28,490 ‫In diesem Fall möchten wir also 11 00:00:28,490 --> 00:00:30,340 ‫nur eine nette, menschenfreundliche Nachricht 12 00:00:30,340 --> 00:00:33,070 ‫senden, damit der Benutzer weiß, was nicht stimmt. 13 00:00:33,070 --> 00:00:34,858 ‫Auf der anderen Seite 14 00:00:34,858 --> 00:00:37,700 ‫möchten wir bei der schriftlichen Entwicklung so viele Informationen 15 00:00:37,700 --> 00:00:40,390 ‫wie möglich über den aufgetretenen Fehler erhalten, und 16 00:00:40,390 --> 00:00:42,950 ‫zwar direkt in der Fehlermeldung, die zurückkommt. 17 00:00:42,950 --> 00:00:45,520 ‫Wir könnten diese Informationen also auch in der 18 00:00:45,520 --> 00:00:48,340 ‫Konsole protokollieren, aber ich denke, es ist in diesem Fall 19 00:00:48,340 --> 00:00:51,150 ‫viel nützlicher, diese Informationen direkt im Postboten zu haben. 20 00:00:51,150 --> 00:00:53,660 ‫Wir wissen also bereits, wie man zwischen 21 00:00:53,660 --> 00:00:56,010 ‫der Entwicklungs- und der Produktionsumgebung unterscheidet. 22 00:00:56,870 --> 00:00:58,213 ‫Also, lass uns das tun. 23 00:00:59,130 --> 00:00:59,963 ‫Also 24 00:01:01,630 --> 00:01:05,010 ‫wenn Prozess. env. node_env ist 25 00:01:06,510 --> 00:01:08,970 ‫gleich development, dann möchten wir 26 00:01:11,810 --> 00:01:13,780 ‫einen Fehlertyp senden und 27 00:01:15,530 --> 00:01:17,060 ‫wenn wir in 28 00:01:17,060 --> 00:01:21,020 ‫der Produktion sind, möchten wir einen einfacheren Fehler senden. 29 00:01:21,020 --> 00:01:21,853 ‫In Ordung. 30 00:01:24,290 --> 00:01:26,913 ‫Also gleich der Produktion. 31 00:01:30,160 --> 00:01:33,343 ‫Okay, greifen wir also zu diesem hier, 32 00:01:34,390 --> 00:01:36,380 ‫also wollen wir bei 33 00:01:36,380 --> 00:01:39,850 ‫der schriftlichen Entwicklung alle Informationen erhalten, die wir können. 34 00:01:39,850 --> 00:01:43,763 ‫Also auch hier mit dem Fehlerstack drucken oder antworten. 35 00:01:48,620 --> 00:01:52,300 ‫Also irr. stack, und dann drucken 36 00:01:52,300 --> 00:01:54,483 ‫wir auch den gesamten Fehler. 37 00:01:56,240 --> 00:02:00,830 ‫Sagen wir Fehler und stellen Sie es in Ordnung. 38 00:02:00,830 --> 00:02:02,003 ‫Andererseits kopieren 39 00:02:03,030 --> 00:02:05,183 ‫wir das jetzt noch einmal. 40 00:02:06,040 --> 00:02:09,350 ‫Wenn wir in der Produktion sind, wollen wir 41 00:02:09,350 --> 00:02:12,493 ‫weder den Stack noch den kompletten Fehler. 42 00:02:13,490 --> 00:02:16,113 ‫Also eigentlich nur der Status und die Nachricht. 43 00:02:19,190 --> 00:02:20,933 ‫Das hier sieht irgendwie 44 00:02:21,930 --> 00:02:24,550 ‫chaotisch aus, also exportieren wir diese in 45 00:02:24,550 --> 00:02:27,440 ‫ihre eigenen Funktionen und auch weil wir hier 46 00:02:27,440 --> 00:02:30,719 ‫unten in diesem else-Zweig viel mehr Code hinzufügen werden. 47 00:02:30,719 --> 00:02:33,730 ‫Es ist ein bisschen sauberer, diese in ihre eigenen 48 00:02:33,730 --> 00:02:35,180 ‫separaten Funktionen zu integrieren. 49 00:02:36,500 --> 00:02:37,550 ‫Nehmen wir 50 00:02:39,540 --> 00:02:41,480 ‫also an, const send error 51 00:02:43,930 --> 00:02:46,470 ‫for dev und diese Funktion sollte dann 52 00:02:46,470 --> 00:02:49,903 ‫den Fehler erhalten, und wir müssen auch den Antwortbetreff übergeben. 53 00:02:51,990 --> 00:02:54,930 ‫Das liegt daran, dass wir die Antwort 54 00:02:54,930 --> 00:02:57,223 ‫tatsächlich so senden können, oder? 55 00:02:58,360 --> 00:03:02,090 ‫Wir benötigen also das Antwortsubjekt, um diesen Code ausführen 56 00:03:02,090 --> 00:03:02,933 ‫zu können. 57 00:03:04,080 --> 00:03:06,510 ‫Hier rufen wir nur send 58 00:03:07,410 --> 00:03:08,990 ‫error dev mit 59 00:03:09,890 --> 00:03:11,263 ‫dem Fehler 60 00:03:11,263 --> 00:03:13,073 ‫und der Antwort auf. 61 00:03:14,270 --> 00:03:15,483 ‫Dann müssen 62 00:03:17,030 --> 00:03:18,030 ‫wir 63 00:03:18,030 --> 00:03:21,783 ‫hier unten eine Fehlerproduktion senden, die 64 00:03:24,830 --> 00:03:26,253 ‫gleichen Argumente. 65 00:03:36,300 --> 00:03:37,500 ‫Und dann hier das gleiche. 66 00:03:43,041 --> 00:03:46,740 ‫Das war also einfach, lassen Sie uns jetzt auf die nächste 67 00:03:46,740 --> 00:03:49,810 ‫Ebene gehen und noch einmal über Betriebsfehler sprechen. 68 00:03:49,810 --> 00:03:53,230 ‫Lassen Sie mich dazu die von uns erstellte 69 00:03:53,230 --> 00:03:56,270 ‫App-Fehlerklasse öffnen und daran erinnern, dass wir 70 00:03:56,270 --> 00:03:57,870 ‫alle Fehler, die 71 00:03:57,870 --> 00:04:02,313 ‫wir erstellen, markieren, indem AppError ist operational auf true gesetzt ist. 72 00:04:03,721 --> 00:04:05,760 ‫Alle Fehler, die wir 73 00:04:05,760 --> 00:04:07,873 ‫selbst erstellen, sind also grundsätzlich Betriebsfehler. 74 00:04:09,100 --> 00:04:11,950 ‫Tatsächlich sind es nur diese Betriebsfehler, bei 75 00:04:11,950 --> 00:04:14,540 ‫denen wir die Fehlermeldung an den Client 76 00:04:14,540 --> 00:04:15,703 ‫senden möchten. 77 00:04:16,720 --> 00:04:18,310 ‫Zumindest in der Produktion. 78 00:04:18,310 --> 00:04:21,900 ‫Wenn wir hingegen einen Programmierfehler oder einen anderen 79 00:04:21,900 --> 00:04:23,880 ‫unbekannten Fehler haben, der 80 00:04:23,880 --> 00:04:26,500 ‫beispielsweise von einem Drittanbieterpaket stammt, möchten 81 00:04:26,500 --> 00:04:29,930 ‫wir keine Fehlermeldung darüber an den Kunden in 82 00:04:29,930 --> 00:04:31,864 ‫der Produktion senden. 83 00:04:31,864 --> 00:04:33,470 ‫Und das nützt also nichts. 84 00:04:33,470 --> 00:04:37,340 ‫Dies ist Betriebseigenschaft hier in unserem Fehlercontroller. 85 00:04:37,340 --> 00:04:40,090 ‫Erinnern Sie sich, wie ich bereits 86 00:04:40,090 --> 00:04:43,693 ‫darüber gesprochen habe, als wir diese Klasse erstellt haben, richtig? 87 00:04:45,580 --> 00:04:48,780 ‫Lassen Sie uns jetzt hierher kommen, um die Fehlerproduktion zu senden 88 00:04:49,730 --> 00:04:50,913 ‫und diesen Test durchzuführen. 89 00:04:52,270 --> 00:04:54,787 ‫Wenn Fehler. isOperational nur 90 00:05:00,630 --> 00:05:05,053 ‫in diesem Fall wollen wir diesen Fehler eigentlich hierher schicken. 91 00:05:06,940 --> 00:05:08,113 ‫In allen 92 00:05:10,070 --> 00:05:11,330 ‫anderen Fällen senden 93 00:05:11,330 --> 00:05:14,580 ‫wir einfach eine sehr allgemeine Fehlermeldung an den Client. 94 00:05:14,580 --> 00:05:17,310 ‫Sagen wir also, res. status und wir 95 00:05:19,400 --> 00:05:22,110 ‫senden einfach einen generischen 500-Code und 96 00:05:23,930 --> 00:05:25,123 ‫dann json. 97 00:05:28,120 --> 00:05:30,363 ‫Der Status wird Fehler sein. 98 00:05:33,230 --> 00:05:36,660 ‫Dann lassen Sie uns einfach eine allgemeine Nachricht senden und sagen, 99 00:05:38,200 --> 00:05:39,033 ‫dass etwas 100 00:05:41,360 --> 00:05:42,573 ‫sehr schief gelaufen ist. 101 00:05:43,690 --> 00:05:46,983 ‫So etwas zu tun ist also ein ganz normales Verfahren. 102 00:05:48,420 --> 00:05:51,133 ‫Lassen Sie mich hier einen Teil des Codes auskommentieren. 103 00:05:54,530 --> 00:05:57,533 ‫Dies ist also ein Betriebsfehler, dem wir vertrauen. 104 00:06:03,700 --> 00:06:06,200 ‫Hier möchten wir eine Nachricht an den Client senden. 105 00:06:06,200 --> 00:06:07,503 ‫Aber in diesem 106 00:06:16,130 --> 00:06:17,973 ‫Fall haben wir hier einen unbekannten 107 00:06:19,080 --> 00:06:22,673 ‫Fehler, und deshalb möchten wir die Details nicht an den Kunden weitergeben. 108 00:06:28,470 --> 00:06:31,380 ‫Also werden wir diese Nachricht dann einfach an den Kunden und 109 00:06:31,380 --> 00:06:33,070 ‫auch für uns selbst senden. 110 00:06:33,070 --> 00:06:35,340 ‫Für uns Entwickler möchten wir 111 00:06:35,340 --> 00:06:38,610 ‫wissen, dass dieser seltsame, unerwartete, unbekannte Fehler aufgetreten ist, 112 00:06:38,610 --> 00:06:41,993 ‫und wir werden ihn tatsächlich in der Konsole protokollieren. 113 00:06:49,100 --> 00:06:50,593 ‫Wir protokollieren zuerst 114 00:06:56,702 --> 00:06:59,369 ‫den Fehler und senden dann eine allgemeine Nachricht. 115 00:07:00,280 --> 00:07:03,270 ‫Sagen wir einfach, Konsole. Fehler, also ist dies ein bisschen 116 00:07:03,270 --> 00:07:05,490 ‫wie eine Konsole. log, aber 117 00:07:05,490 --> 00:07:07,870 ‫es ist wirklich spezifisch für Fehler und 118 00:07:07,870 --> 00:07:10,670 ‫ich glaube, die Ausgabe sieht dann etwas anders aus. 119 00:07:12,090 --> 00:07:15,670 ‫Also Fehler, fügen wir hier einige Emojis hinzu, um sie in unseren 120 00:07:15,670 --> 00:07:16,543 ‫Protokollen sichtbar 121 00:07:17,950 --> 00:07:20,360 ‫zu machen, und protokollieren Sie dann auch den Fehler. 122 00:07:20,360 --> 00:07:23,213 ‫Jetzt gibt es echte Logging-Bibliotheken auf mpm, die wir hier 123 00:07:23,213 --> 00:07:24,550 ‫verwenden könnten, anstatt 124 00:07:24,550 --> 00:07:28,030 ‫nur diese einfache Konsole zu haben. Fehler, aber nur das 125 00:07:28,030 --> 00:07:30,430 ‫Protokollieren des Fehlers in der Konsole macht 126 00:07:30,430 --> 00:07:32,220 ‫ihn in den Protokollen auf 127 00:07:32,220 --> 00:07:34,363 ‫der von Ihnen verwendeten Hosting-Plattform sichtbar. 128 00:07:35,486 --> 00:07:39,200 ‫Ich denke, das reicht bei dieser einfachen Anwendung für den 129 00:07:39,200 --> 00:07:40,073 ‫Moment aus. 130 00:07:41,110 --> 00:07:42,860 ‫Zum Beispiel werden wir Heroku 131 00:07:42,860 --> 00:07:45,710 ‫am Ende des Kurses verwenden, um unsere Anwendung bereitzustellen. 132 00:07:45,710 --> 00:07:47,600 ‫Wenn dann ein solcher Fehler 133 00:07:47,600 --> 00:07:49,970 ‫auftritt, wird er in der Konsole protokolliert. 134 00:07:49,970 --> 00:07:54,180 ‫Auf der Heroku-Plattform haben wir dann Zugriff auf diese Protokolle. 135 00:07:54,180 --> 00:07:57,080 ‫Wir können uns diese Protokolle weiter ansehen und dann 136 00:07:57,080 --> 00:07:59,220 ‫dort diese unerwarteten Fehler finden, um 137 00:07:59,220 --> 00:08:00,670 ‫sie dann zu beheben. 138 00:08:01,678 --> 00:08:04,470 ‫Im Moment bauen wir hier tatsächlich 139 00:08:04,470 --> 00:08:07,000 ‫bereits eine Art ausgeklügelter und 140 00:08:07,000 --> 00:08:08,713 ‫realitätsnaher Fehlerbehandlungsmechanismus. 141 00:08:09,720 --> 00:08:13,240 ‫Fassen wir also kurz zusammen, was wir hier gerade gemacht haben. 142 00:08:13,240 --> 00:08:16,380 ‫Wir unterscheiden zwischen Fehlern in der Entwicklung und in 143 00:08:16,380 --> 00:08:17,373 ‫der Produktion. 144 00:08:18,720 --> 00:08:21,420 ‫Wenn wir in der Produktion sind, senden 145 00:08:21,420 --> 00:08:22,970 ‫wir den Fehler mit 146 00:08:22,970 --> 00:08:26,050 ‫dieser Funktion hier, die dann so viele Details wie 147 00:08:26,050 --> 00:08:27,340 ‫möglich an 148 00:08:27,340 --> 00:08:28,997 ‫den Client sendet, damit wir 149 00:08:28,997 --> 00:08:31,730 ‫wirklich alle Informationen erhalten, um den Fehler loszuwerden. 150 00:08:31,730 --> 00:08:33,332 ‫Wenn es sich um 151 00:08:33,332 --> 00:08:35,670 ‫einen Programmierfehler oder einen Betriebsfehler handelt, 152 00:08:35,670 --> 00:08:39,083 ‫möchten wir trotzdem wirklich alles sehen, was vor sich geht. 153 00:08:40,670 --> 00:08:42,000 ‫Wenn wir in 154 00:08:42,000 --> 00:08:44,330 ‫der Produktion sind, was wohl der 155 00:08:44,330 --> 00:08:47,090 ‫wichtigste Teil unserer Anwendung ist, dann unterscheiden wir 156 00:08:47,090 --> 00:08:48,590 ‫zwischen Betriebsfehlern, also Fehlern, 157 00:08:48,590 --> 00:08:50,950 ‫die wir kennen und denen wir 158 00:08:50,950 --> 00:08:54,163 ‫vertrauen, und anderen Fehlern, die irgendwie unerwartet sein können. 159 00:08:55,660 --> 00:08:58,800 ‫Wenn der Fehler betriebsbereit ist, also beispielsweise der Benutzer 160 00:08:58,800 --> 00:09:01,530 ‫versucht hat, auf eine nicht vorhandene Route zuzugreifen, 161 00:09:01,530 --> 00:09:03,680 ‫oder versucht hat, ungültige Daten einzugeben, 162 00:09:03,680 --> 00:09:05,253 ‫sind dies alle Betriebsfehler. 163 00:09:05,253 --> 00:09:08,130 ‫Dann können wir entsprechende Fehlermeldungen senden, damit der 164 00:09:08,130 --> 00:09:10,880 ‫Kunde weiß, was schief gelaufen ist. 165 00:09:10,880 --> 00:09:13,820 ‫Auf der anderen Seite haben wir diese unbekannten Fehler 166 00:09:13,820 --> 00:09:16,380 ‫oder unerwarteten Fehler, und in diesem Fall 167 00:09:16,380 --> 00:09:19,420 ‫sagen wir ganz einfach, dass etwas schief gelaufen ist. 168 00:09:19,420 --> 00:09:21,670 ‫Dann loggen Sie den Fehler auch in unsere Konsole 169 00:09:21,670 --> 00:09:24,433 ‫ein, damit wir wissen, dass er aufgetreten ist und ihn dann beheben können. 170 00:09:25,510 --> 00:09:27,080 ‫Damit dies funktioniert, müssen 171 00:09:27,080 --> 00:09:29,160 ‫wir etwas wirklich, wirklich Wichtiges 172 00:09:29,160 --> 00:09:30,193 ‫tun. 173 00:09:31,040 --> 00:09:33,340 ‫Im Moment gibt es Fehler, die 174 00:09:33,340 --> 00:09:37,550 ‫zum Beispiel von MongoDB kommen, die wir nicht als betriebsbereit markieren. 175 00:09:37,550 --> 00:09:40,970 ‫In diesem Fall würden sie jetzt einfach mit 176 00:09:40,970 --> 00:09:43,500 ‫dieser generischen Fehlermeldung hier behandelt. 177 00:09:43,500 --> 00:09:45,330 ‫Zum Beispiel ein Validierungsfehler. 178 00:09:45,330 --> 00:09:48,000 ‫Im Moment ist das ein Fehler, der 179 00:09:48,000 --> 00:09:51,356 ‫von MongoDB kommt und nicht von unserer eigenen App-Fehlerklasse. 180 00:09:51,356 --> 00:09:54,869 ‫Wir erstellen diese Fehler nicht selbst. 181 00:09:54,869 --> 00:09:58,800 ‫Auch hier sind sie im Moment noch nicht als betriebsbereit markiert, 182 00:09:58,800 --> 00:10:02,130 ‫aber wir müssen sie natürlich als betriebsbereit markieren, damit 183 00:10:02,130 --> 00:10:04,680 ‫wir dann die entsprechende Fehlermeldung an 184 00:10:04,680 --> 00:10:06,400 ‫den Client zurücksenden können. 185 00:10:06,400 --> 00:10:08,360 ‫In dem gerade erwähnten Beispiel 186 00:10:08,360 --> 00:10:10,263 ‫sind die Eingabedaten ungültig. 187 00:10:11,250 --> 00:10:14,230 ‫Es gibt noch zwei oder drei weitere Fehler, die wir 188 00:10:14,230 --> 00:10:15,793 ‫selbst als funktionsfähig markieren müssen. 189 00:10:16,930 --> 00:10:18,020 ‫Also werden wir 190 00:10:19,410 --> 00:10:20,670 ‫das hier unten tun. 191 00:10:20,670 --> 00:10:22,193 ‫In diesem else-Block werden 192 00:10:23,400 --> 00:10:25,850 ‫wir das in den nächsten Vorlesungen tun.