1 00:00:01,120 --> 00:00:03,120 ‫Kursleiter: Lassen Sie uns in diesem Video über 2 00:00:03,120 --> 00:00:06,770 ‫etwas sprechen, das wir in node. js namens unbehandelte Ablehnungen und 3 00:00:06,770 --> 00:00:09,543 ‫erfahren Sie dann, wie wir sie tatsächlich handhaben können. 4 00:00:10,970 --> 00:00:14,400 ‫An dieser Stelle haben wir Fehler in 5 00:00:14,400 --> 00:00:16,330 ‫unserer Express-Anwendung erfolgreich 6 00:00:16,330 --> 00:00:19,970 ‫behandelt, indem wir operative asynchrone Fehler an 7 00:00:19,970 --> 00:00:22,410 ‫eine globale Fehlerbehandlungs-Middleware weitergegeben haben. 8 00:00:22,410 --> 00:00:26,200 ‫Dieser sendet dann abhängig von der Art 9 00:00:26,200 --> 00:00:30,510 ‫des aufgetretenen Fehlers relevante Fehlermeldungen an den Client zurück, oder? 10 00:00:30,510 --> 00:00:34,730 ‫Es können jedoch auch Fehler außerhalb von Express auftreten 11 00:00:34,730 --> 00:00:38,520 ‫und ein gutes Beispiel dafür in unserer aktuellen 12 00:00:38,520 --> 00:00:40,810 ‫Anwendung ist die mongodb-Datenbankverbindung. 13 00:00:40,810 --> 00:00:43,700 ‫Stellen Sie sich also vor, die Datenbank ist aus irgendeinem Grund ausgefallen 14 00:00:43,700 --> 00:00:46,000 ‫oder wir können uns aus irgendeinem Grund nicht anmelden. 15 00:00:46,000 --> 00:00:47,920 ‫Und dann gibt es auch Fehler, 16 00:00:47,920 --> 00:00:49,610 ‫mit denen wir umgehen müssen. 17 00:00:49,610 --> 00:00:52,800 ‫Aber sie sind nicht in unserer Express-Anwendung aufgetreten und 18 00:00:52,800 --> 00:00:55,810 ‫daher wird unsere Fehlerbehandlung, die wir implementiert haben, 19 00:00:55,810 --> 00:00:58,560 ‫diese Fehler natürlich nicht abfangen, oder? 20 00:00:58,560 --> 00:01:01,790 ‫Um zu testen, was 21 00:01:01,790 --> 00:01:05,110 ‫passiert, ändern wir unser mongodb-Passwort, okay? 22 00:01:05,110 --> 00:01:06,960 ‫Denn auf diese Weise 23 00:01:06,960 --> 00:01:10,180 ‫werden wir keine Verbindung zur Datenbank herstellen können, oder? 24 00:01:10,180 --> 00:01:13,110 ‫Und so sollten wir dann eine Art Fehler 25 00:01:13,110 --> 00:01:15,510 ‫bekommen, also gehen wir hier zu 26 00:01:15,510 --> 00:01:18,633 ‫unserer Serverdatei und speichern sie, um unseren Server neu 27 00:01:20,710 --> 00:01:23,040 ‫zu laden, erhöhen wir sie 28 00:01:23,040 --> 00:01:26,120 ‫hier, und tatsächlich haben wir hier eine unbehandelte Versprechensablehnung. 29 00:01:26,120 --> 00:01:29,510 ‫Und das ist eigentlich das Thema dieses Videos. 30 00:01:29,510 --> 00:01:33,600 ‫Eine nicht behandelte Versprechensablehnung bedeutet also, dass irgendwo in unserem 31 00:01:33,600 --> 00:01:37,140 ‫Code ein Versprechen vorhanden ist, das abgelehnt wurde. 32 00:01:37,140 --> 00:01:41,270 ‫Aber diese Ablehnung wurde nirgendwo behandelt, in Ordnung? 33 00:01:41,270 --> 00:01:44,920 ‫Und hier unten sehen Sie auch eine Veraltungswarnung, die 34 00:01:44,920 --> 00:01:48,008 ‫besagt, dass in Zukunft nicht behandelte 35 00:01:48,008 --> 00:01:51,710 ‫Ablehnungen einfach das laufende Knotenprogramm verlassen, was möglicherweise nicht 36 00:01:51,710 --> 00:01:54,940 ‫immer das ist, was Sie wollen, okay? 37 00:01:54,940 --> 00:01:57,450 ‫Lassen Sie uns also dieses Problem 38 00:01:57,450 --> 00:02:00,000 ‫beheben und diese unbehandelte Ablehnung von Versprechen loswerden. 39 00:02:00,000 --> 00:02:01,910 ‫In diesem einfachen Beispiel hier 40 00:02:01,910 --> 00:02:03,270 ‫wäre es eigentlich 41 00:02:03,270 --> 00:02:05,770 ‫ganz einfach, mit dieser Ablehnung umzugehen, oder? 42 00:02:05,770 --> 00:02:08,060 ‫Alles, was wir tun müssen, wäre, 43 00:02:08,060 --> 00:02:11,550 ‫zu diesem Codeabschnitt zu gelangen, in dem unsere Verbindung tatsächlich hergestellt 44 00:02:11,550 --> 00:02:14,100 ‫wird, und dann dort einen Catch-Handler hinzuzufügen, richtig? 45 00:02:14,100 --> 00:02:16,580 ‫Also ein bisschen so, und dann hier drin, 46 00:02:16,580 --> 00:02:18,640 ‫könnten wir mit dieser Ablehnung umgehen 47 00:02:18,640 --> 00:02:20,970 ‫und würden dann diesen Fehler nicht mehr bekommen. 48 00:02:20,970 --> 00:02:22,820 ‫Lass mich dir das nur schnell zeigen. 49 00:02:29,905 --> 00:02:31,960 ‫Versuchen Sie es also noch einmal. 50 00:02:31,960 --> 00:02:35,630 ‫Und so erhalten Sie jetzt einen Fehler, der natürlich 51 00:02:35,630 --> 00:02:37,950 ‫das Ergebnis dieses Protokolls hier 52 00:02:37,950 --> 00:02:41,010 ‫ist, aber natürlich erhalten wir keine unbehandelte 53 00:02:41,010 --> 00:02:45,060 ‫Versprechensablehnung, weil wir es hier tatsächlich behandelt haben, in Ordnung? 54 00:02:45,060 --> 00:02:48,580 ‫Das würde natürlich funktionieren, aber ich möchte Ihnen wirklich zeigen, wie 55 00:02:48,580 --> 00:02:51,720 ‫Sie global mit nicht bearbeiteten abgelehnten Zusagen umgehen, denn 56 00:02:51,720 --> 00:02:54,680 ‫bei einer größeren Bewerbung kann es etwas schwieriger 57 00:02:54,680 --> 00:02:57,860 ‫werden, immer den Überblick über alle Zusagen zu behalten, die 58 00:02:57,860 --> 00:03:00,590 ‫bei einigen abgelehnt werden könnten Punkt, okay? 59 00:03:00,590 --> 00:03:03,280 ‫Und so kann es sein, dass Sie irgendwann 60 00:03:03,280 --> 00:03:06,690 ‫irgendwo eine unbehandelte Ablehnung von Versprechen haben und lassen Sie mich Ihnen 61 00:03:06,690 --> 00:03:09,860 ‫zeigen, wie Sie damit im Grunde genommen global umgehen können. 62 00:03:09,860 --> 00:03:14,070 ‫Lassen Sie uns jetzt lernen, wie man mit unbehandelten Ablehnungen umgeht, und 63 00:03:14,070 --> 00:03:16,160 ‫das werden wir hier tun. 64 00:03:16,160 --> 00:03:19,530 ‫Erinnern Sie sich also daran, wie wir in einem 65 00:03:19,530 --> 00:03:21,900 ‫der ersten Abschnitte des Kurses über Ereignisse 66 00:03:21,900 --> 00:03:24,080 ‫und Ereignishörer gesprochen haben, richtig? 67 00:03:24,080 --> 00:03:28,010 ‫Und jetzt ist es an der Zeit, dieses Wissen tatsächlich zu nutzen. 68 00:03:28,010 --> 00:03:30,940 ‫Jedes Mal, wenn es irgendwo in 69 00:03:30,940 --> 00:03:34,180 ‫unserer Anwendung eine unbehandelte Ablehnung gibt, gibt 70 00:03:34,180 --> 00:03:37,470 ‫das Prozessobjekt ein Objekt namens unbehandelte Ablehnung 71 00:03:37,470 --> 00:03:41,223 ‫aus, und wir können dieses Ereignis einfach so abonnieren. 72 00:03:42,250 --> 00:03:46,903 ‫Also verarbeiten. an, merken Sie sich und 73 00:03:48,004 --> 00:03:52,053 ‫dann den Namen des Ereignisses, unbehandelte Zurückweisung, und 74 00:03:52,930 --> 00:03:55,240 ‫dann erhält die 75 00:03:55,240 --> 00:03:59,369 ‫Rückruffunktion hier einen Fehler, und so können wir 76 00:03:59,369 --> 00:04:02,793 ‫den Fehler tatsächlich in der Konsole protokollieren. 77 00:04:03,780 --> 00:04:08,653 ‫Verwenden wir also err. Name und Fehler. Botschaft. 78 00:04:09,620 --> 00:04:11,640 ‫Dies sind also einige Standardeinstellungen, die wir 79 00:04:12,500 --> 00:04:16,073 ‫für alle Fehler in node. js, in Ordnung? 80 00:04:17,570 --> 00:04:20,930 ‫Okay, und nach dem Speichern bekommen wir schon 81 00:04:20,930 --> 00:04:24,410 ‫hier unten den Namen des Fehlers und auch die Fehlermeldung. 82 00:04:24,410 --> 00:04:27,940 ‫Also schlechte Authentifizierung, was natürlich daran liegt, dass wir das 83 00:04:27,940 --> 00:04:29,490 ‫falsche Passwort haben. 84 00:04:29,490 --> 00:04:32,360 ‫Und so wird die unbehandelte Ablehnung des Versprechens 85 00:04:32,360 --> 00:04:33,960 ‫jetzt tatsächlich behandelt. 86 00:04:33,960 --> 00:04:37,430 ‫Und natürlich wird nicht nur die von dieser fehlgeschlagenen Verbindung, 87 00:04:37,430 --> 00:04:40,410 ‫sondern auch jede andere Ablehnung des Versprechens behandelt, 88 00:04:40,410 --> 00:04:44,260 ‫die wir möglicherweise nicht irgendwo in der Anwendung finden, hier in diesem 89 00:04:44,260 --> 00:04:46,880 ‫Finale, nennen wir es Sicherheitsnetz, in Ordnung? 90 00:04:46,880 --> 00:04:49,890 ‫Wir müssen also immer davon ausgehen, dass wir 91 00:04:49,890 --> 00:04:51,410 ‫als Programmierer Fehler machen. 92 00:04:51,410 --> 00:04:54,740 ‫Es ist also immer am besten, einen solchen zentralen Ort zu haben, 93 00:04:54,740 --> 00:04:56,560 ‫an dem alle Ablehnungen von 94 00:04:56,560 --> 00:04:59,132 ‫Versprechen wie ein letztes Sicherheitsnetz behandelt werden, in Ordnung? 95 00:04:59,132 --> 00:05:01,800 ‫Wenn wir nun wirklich ein Problem 96 00:05:01,800 --> 00:05:04,890 ‫mit der Datenbankverbindung haben, wie in diesem Beispiel, 97 00:05:04,890 --> 00:05:07,840 ‫dann wird unsere Anwendung überhaupt nicht funktionieren. 98 00:05:07,840 --> 00:05:09,760 ‫Also alles, was wir hier 99 00:05:09,760 --> 00:05:12,820 ‫wirklich tun können, ist, unsere Anwendung zu schließen, in Ordnung? 100 00:05:12,820 --> 00:05:17,053 ‫Um die Anwendung herunterzufahren, verwenden wir also process. Ausfahrt. 101 00:05:18,140 --> 00:05:20,420 ‫Und das haben wir tatsächlich schon 102 00:05:20,420 --> 00:05:22,850 ‫früher in diesem Skript verwendet, in dem wir 103 00:05:22,850 --> 00:05:27,080 ‫alle Daten aus der JSON-Datei in die Datenbank importiert haben, erinnerst du dich? 104 00:05:27,080 --> 00:05:29,660 ‫Also verarbeiten. exit und dann hier 105 00:05:29,660 --> 00:05:31,810 ‫rein, wir können tatsächlich einen Code übergeben. 106 00:05:31,810 --> 00:05:34,140 ‫Und der Code Null steht 107 00:05:34,140 --> 00:05:36,800 ‫für Erfolg und Eins für unabgefangene Ausnahme. 108 00:05:36,800 --> 00:05:40,230 ‫Und das wird hier normalerweise verwendet, in Ordnung? 109 00:05:40,230 --> 00:05:43,400 ‫Normalerweise werden Sie es also immer so sehen. 110 00:05:43,400 --> 00:05:46,970 ‫Und fügen wir hier einfach wie ein Protokoll hinzu, Konsole. log unhandler die 111 00:05:50,293 --> 00:05:51,973 ‫Ablehnung, etwa 112 00:05:56,020 --> 00:05:57,560 ‫so. 113 00:05:57,560 --> 00:05:59,860 ‫Ihr seht also, das gefällt mir sehr, dieses hier. 114 00:06:02,910 --> 00:06:04,650 ‫Lassen Sie dies einfach Knoten sein ... 115 00:06:04,650 --> 00:06:06,730 ‫Nicht wirklich Benutzer, aber 116 00:06:06,730 --> 00:06:09,320 ‫unser Protokoll, das wir schließen, in Ordnung? 117 00:06:09,320 --> 00:06:12,330 ‫Und jetzt sehen Sie, dass die App tatsächlich abgestürzt ist. 118 00:06:12,330 --> 00:06:16,515 ‫Und das liegt an diesem Prozess. geh hier raus, in Ordnung? 119 00:06:16,515 --> 00:06:18,860 ‫Nun, es gibt nur ein Problem mit der Art 120 00:06:18,860 --> 00:06:20,480 ‫und Weise, wie wir es 121 00:06:20,480 --> 00:06:23,430 ‫gerade implementiert haben, und das ist, dass wir es hier so 122 00:06:23,430 --> 00:06:26,990 ‫implementieren, dass es einfach verarbeitet wird. exit ist eine 123 00:06:26,990 --> 00:06:30,420 ‫sehr abrupte Möglichkeit, das Programm zu beenden, da 124 00:06:30,420 --> 00:06:34,030 ‫dies alle derzeit noch laufenden oder anstehenden Anfragen 125 00:06:34,030 --> 00:06:38,300 ‫sofort abbricht und daher möglicherweise keine gute Idee ist, okay? 126 00:06:38,300 --> 00:06:41,550 ‫Normalerweise fahren wir also ordnungsgemäß herunter, wo 127 00:06:41,550 --> 00:06:44,210 ‫wir zuerst den Server schließen 128 00:06:44,210 --> 00:06:47,140 ‫und erst dann die Anwendung herunterfahren, okay? 129 00:06:47,140 --> 00:06:47,973 ‫Also lass uns... 130 00:06:47,973 --> 00:06:51,440 ‫Bevor wir das tun, müssen wir 131 00:06:51,440 --> 00:06:55,670 ‫den Server hier grundsätzlich in einer Variablen speichern, okay? 132 00:06:55,670 --> 00:06:59,650 ‫Und so das Ergebnis des Aufrufens der App. listen ist ein Server und 133 00:06:59,650 --> 00:07:04,650 ‫auf diesem Server können wir jetzt Server sagen. close was, wie der Name 134 00:07:05,810 --> 00:07:08,400 ‫schon sagt, den Server schließt und 135 00:07:08,400 --> 00:07:10,490 ‫dann, nachdem das erledigt 136 00:07:10,490 --> 00:07:14,810 ‫ist, diese Callback-Funktion ausführt, die wir ihm übergeben haben, also 137 00:07:14,810 --> 00:07:16,130 ‫nur hier, 138 00:07:16,130 --> 00:07:19,310 ‫wo wir dann den Server herunterfahren, okay? 139 00:07:19,310 --> 00:07:22,240 ‫Und so tun Sie dies, indem Sie server. close, wir geben 140 00:07:22,240 --> 00:07:25,630 ‫dem Server im Grunde Zeit, alle Anfragen zu beenden, die 141 00:07:25,630 --> 00:07:28,890 ‫zu diesem Zeitpunkt noch ausstehen oder bearbeitet werden, und 142 00:07:28,890 --> 00:07:31,180 ‫erst danach wird der Server dann 143 00:07:31,180 --> 00:07:32,910 ‫im Grunde beendet, in Ordnung? 144 00:07:32,910 --> 00:07:34,620 ‫Wenn wir ihm also 145 00:07:34,620 --> 00:07:37,020 ‫einen Safe geben, wird es nicht genau gleich 146 00:07:37,020 --> 00:07:39,880 ‫aussehen, denn (lacht) ja, wir sind wie die einzigen, 147 00:07:39,880 --> 00:07:42,850 ‫die wirklich auf diese Anwendung zugreifen, aber in der 148 00:07:42,850 --> 00:07:45,960 ‫realen Welt sollten wir es immer so machen, okay ? 149 00:07:45,960 --> 00:07:48,200 ‫Und natürlich ist es nicht wirklich 150 00:07:48,200 --> 00:07:50,520 ‫ideal, dass die Anwendung abgestürzt ist, oder? 151 00:07:50,520 --> 00:07:53,120 ‫Denn im Moment läuft die App natürlich 152 00:07:53,120 --> 00:07:55,448 ‫nicht, sie funktioniert überhaupt nicht, oder? 153 00:07:55,448 --> 00:07:59,570 ‫In einer Produktions-App auf einem Webserver haben wir normalerweise ein Tool, 154 00:07:59,570 --> 00:08:01,690 ‫das die Anwendung direkt nach dem 155 00:08:01,690 --> 00:08:05,100 ‫Absturz neu startet, oder auch einige der Plattformen, die 156 00:08:05,100 --> 00:08:08,120 ‫den Knoten hosten. js macht 157 00:08:08,120 --> 00:08:11,164 ‫das automatisch von selbst, okay? 158 00:08:11,164 --> 00:08:13,920 ‫Denn natürlich wollen wir die Bewerbung nicht 159 00:08:13,920 --> 00:08:15,590 ‫ewig so hängen lassen. 160 00:08:15,590 --> 00:08:18,420 ‫Das ist also auch nicht nützlich, in Ordnung? 161 00:08:18,420 --> 00:08:20,410 ‫Und so gehen Sie im 162 00:08:20,410 --> 00:08:22,590 ‫Grunde genommen mit unbehandelten, abgelehnten Versprechen um. 163 00:08:22,590 --> 00:08:25,130 ‫Im Grunde hören wir also wieder auf 164 00:08:25,130 --> 00:08:27,930 ‫dieses nicht behandelte Zurückweisungsereignis, das es uns dann 165 00:08:27,930 --> 00:08:30,100 ‫ermöglicht, alle Fehler zu 166 00:08:30,100 --> 00:08:32,280 ‫behandeln, die in asynchronem Code auftreten 167 00:08:32,280 --> 00:08:34,470 ‫und die zuvor nicht behandelt wurden. 168 00:08:34,470 --> 00:08:38,050 ‫Aber jetzt könnten Sie sich fragen, was ist mit dem synchronen Code? 169 00:08:38,050 --> 00:08:40,110 ‫Wo sollen wir das handhaben? 170 00:08:40,110 --> 00:08:43,020 ‫Und die Antwort darauf liegt, wie Sie sich vorstellen 171 00:08:43,020 --> 00:08:44,523 ‫können, im nächsten Video.