1 00:00:01,120 --> 00:00:03,120 ‫Istruttore: In questo video, parliamo di 2 00:00:03,120 --> 00:00:06,770 ‫qualcosa che abbiamo in node. js ha chiamato rifiuti non 3 00:00:06,770 --> 00:00:09,543 ‫gestiti e quindi impara come possiamo effettivamente gestirli. 4 00:00:10,970 --> 00:00:14,400 ‫Quindi, a questo punto, abbiamo gestito con successo 5 00:00:14,400 --> 00:00:16,330 ‫gli errori nella nostra 6 00:00:16,330 --> 00:00:19,970 ‫applicazione express passando gli errori operativi asincroni in un 7 00:00:19,970 --> 00:00:22,410 ‫middleware di gestione degli errori globale. 8 00:00:22,410 --> 00:00:26,200 ‫Questo, quindi, invia messaggi di errore rilevanti al client 9 00:00:26,200 --> 00:00:30,510 ‫a seconda del tipo di errore che si è verificato, giusto? 10 00:00:30,510 --> 00:00:34,730 ‫Tuttavia, potrebbero verificarsi errori anche al di fuori di express e 11 00:00:34,730 --> 00:00:38,520 ‫un buon esempio di ciò nella nostra applicazione corrente è 12 00:00:38,520 --> 00:00:40,810 ‫la connessione al database mongodb. 13 00:00:40,810 --> 00:00:43,700 ‫Quindi immagina che il database sia inattivo per qualche motivo 14 00:00:43,700 --> 00:00:46,000 ‫o per qualche motivo, non possiamo accedere. 15 00:00:46,000 --> 00:00:47,920 ‫E in tal caso, ci sono 16 00:00:47,920 --> 00:00:49,610 ‫anche errori che dobbiamo gestire. 17 00:00:49,610 --> 00:00:52,800 ‫Ma non si sono verificati all'interno della nostra applicazione express 18 00:00:52,800 --> 00:00:55,810 ‫e quindi, ovviamente, il nostro gestore di errori che 19 00:00:55,810 --> 00:00:58,560 ‫abbiamo implementato non rileverà questi errori, giusto? 20 00:00:58,560 --> 00:01:01,790 ‫E quindi, solo per testare cosa succede, 21 00:01:01,790 --> 00:01:05,110 ‫andiamo avanti e cambiamo la nostra password mongodb, ok? 22 00:01:05,110 --> 00:01:06,960 ‫Perché in questo modo 23 00:01:06,960 --> 00:01:10,180 ‫non saremo in grado di connetterci al database, giusto? 24 00:01:10,180 --> 00:01:13,110 ‫E quindi dovremmo ricevere un qualche tipo di 25 00:01:13,110 --> 00:01:15,510 ‫errore, quindi andiamo qui nel nostro 26 00:01:15,510 --> 00:01:18,633 ‫file del server e salviamolo per ricaricare il nostro 27 00:01:20,710 --> 00:01:23,040 ‫server, aumentiamolo qui, e infatti, 28 00:01:23,040 --> 00:01:26,120 ‫qui abbiamo un rifiuto della promessa non gestito. 29 00:01:26,120 --> 00:01:29,510 ‫E quindi questo è in realtà l'argomento di questo video. 30 00:01:29,510 --> 00:01:33,600 ‫Quindi un rifiuto di una promessa non gestita significa che da qualche parte 31 00:01:33,600 --> 00:01:37,140 ‫nel nostro codice c'è una promessa che è stata rifiutata. 32 00:01:37,140 --> 00:01:41,270 ‫Ma quel rifiuto non è stato gestito da nessuna parte, va bene? 33 00:01:41,270 --> 00:01:44,920 ‫E qui sotto, vedi anche un avviso di deprecazione che 34 00:01:44,920 --> 00:01:48,008 ‫dice che in futuro i rifiuti non 35 00:01:48,008 --> 00:01:51,710 ‫gestiti usciranno semplicemente dal programma del nodo in esecuzione, che 36 00:01:51,710 --> 00:01:54,940 ‫potrebbe non essere sempre quello che vuoi, ok? 37 00:01:54,940 --> 00:01:57,450 ‫Quindi risolviamo questo problema e liberiamoci 38 00:01:57,450 --> 00:02:00,000 ‫di questo rifiuto non gestito della promessa. 39 00:02:00,000 --> 00:02:01,910 ‫Ora, in questo semplice esempio 40 00:02:01,910 --> 00:02:03,270 ‫qui, sarebbe in 41 00:02:03,270 --> 00:02:05,770 ‫realtà abbastanza facile gestire quel rifiuto, giusto? 42 00:02:05,770 --> 00:02:08,060 ‫Tutto quello che dovremo fare sarebbe venire qui 43 00:02:08,060 --> 00:02:11,550 ‫a questo pezzo di codice in cui la nostra connessione è effettivamente stabilita 44 00:02:11,550 --> 00:02:14,100 ‫e quindi aggiungere un gestore di cattura lì, giusto? 45 00:02:14,100 --> 00:02:16,580 ‫Quindi un po' così, e poi qui 46 00:02:16,580 --> 00:02:18,640 ‫dentro, potremmo gestire quel rifiuto 47 00:02:18,640 --> 00:02:20,970 ‫e quindi non otterremmo più questo errore. 48 00:02:20,970 --> 00:02:22,820 ‫Lascia che te lo mostri velocemente. 49 00:02:29,905 --> 00:02:31,960 ‫Quindi riprova. 50 00:02:31,960 --> 00:02:35,630 ‫E così ora, ottieni un errore che è ovviamente il 51 00:02:35,630 --> 00:02:37,950 ‫risultato di questo registro qui, ma 52 00:02:37,950 --> 00:02:41,010 ‫ovviamente non otteniamo alcun rifiuto non gestito della 53 00:02:41,010 --> 00:02:45,060 ‫promessa, di nuovo, perché in realtà l'abbiamo gestito qui, va bene? 54 00:02:45,060 --> 00:02:48,580 ‫Quindi questo funzionerebbe, ovviamente, ma voglio davvero mostrarti come gestire 55 00:02:48,580 --> 00:02:51,720 ‫globalmente le promesse rifiutate non gestite, perché in un'applicazione 56 00:02:51,720 --> 00:02:54,680 ‫più grande, può diventare un po' più difficile 57 00:02:54,680 --> 00:02:57,860 ‫tenere sempre traccia di tutte le promesse che potrebbero 58 00:02:57,860 --> 00:03:00,590 ‫essere rifiutate in alcuni punto, ok? 59 00:03:00,590 --> 00:03:03,280 ‫E così ad un certo punto, potresti avere 60 00:03:03,280 --> 00:03:06,690 ‫qualche rifiuto non gestito della promessa da qualche parte e quindi lascia 61 00:03:06,690 --> 00:03:09,860 ‫che ti mostri come affrontarlo a livello globale in pratica. 62 00:03:09,860 --> 00:03:14,070 ‫E quindi ora impariamo come gestire i rifiuti non gestiti e 63 00:03:14,070 --> 00:03:16,160 ‫lo faremo proprio qui. 64 00:03:16,160 --> 00:03:19,530 ‫E allora ricordate come in una delle prime sezioni 65 00:03:19,530 --> 00:03:21,900 ‫del corso abbiamo parlato di eventi 66 00:03:21,900 --> 00:03:24,080 ‫e ascoltatori di eventi, giusto? 67 00:03:24,080 --> 00:03:28,010 ‫E quindi ora è il momento di usare effettivamente quella conoscenza. 68 00:03:28,010 --> 00:03:30,940 ‫Quindi, ogni volta che c'è un rifiuto 69 00:03:30,940 --> 00:03:34,180 ‫non gestito da qualche parte nella nostra applicazione, 70 00:03:34,180 --> 00:03:37,470 ‫l'oggetto processo emetterà un oggetto chiamato rifiuto non gestito 71 00:03:37,470 --> 00:03:41,223 ‫e quindi possiamo iscriverci a quell'evento proprio in questo modo. 72 00:03:42,250 --> 00:03:46,903 ‫Quindi processo. on, ricorda, e poi 73 00:03:48,004 --> 00:03:52,053 ‫il nome dell'evento, il rifiuto non gestito, e 74 00:03:52,930 --> 00:03:55,240 ‫quindi la funzione 75 00:03:55,240 --> 00:03:59,369 ‫di callback qui riceve un errore, quindi andiamo 76 00:03:59,369 --> 00:04:02,793 ‫avanti e registriamo l'errore nella console. 77 00:04:03,780 --> 00:04:08,653 ‫Quindi usiamo err. nome ed err. Messaggio. 78 00:04:09,620 --> 00:04:11,640 ‫Quindi questi sono una specie di default che 79 00:04:12,500 --> 00:04:16,073 ‫abbiamo su tutti gli errori in node. js, va bene? 80 00:04:17,570 --> 00:04:20,930 ‫Ok, e dopo aver salvato, abbiamo già qui 81 00:04:20,930 --> 00:04:24,410 ‫sotto il nome dell'errore e anche il messaggio di errore. 82 00:04:24,410 --> 00:04:27,940 ‫Quindi pessima autenticazione perché, ovviamente, abbiamo la 83 00:04:27,940 --> 00:04:29,490 ‫password sbagliata. 84 00:04:29,490 --> 00:04:32,360 ‫E quindi proprio ora, il rifiuto della promessa non 85 00:04:32,360 --> 00:04:33,960 ‫gestita ora viene effettivamente gestito. 86 00:04:33,960 --> 00:04:37,430 ‫E ovviamente, non solo quello di questa connessione fallita, ma 87 00:04:37,430 --> 00:04:40,410 ‫qualsiasi altro rifiuto della promessa che potremmo non 88 00:04:40,410 --> 00:04:44,260 ‫rilevare da qualche parte nell'applicazione viene gestito qui in questa finale, 89 00:04:44,260 --> 00:04:46,880 ‫chiamiamola rete di sicurezza, va bene? 90 00:04:46,880 --> 00:04:49,890 ‫Quindi dobbiamo sempre presumere che noi come 91 00:04:49,890 --> 00:04:51,410 ‫programmatori faremo errori. 92 00:04:51,410 --> 00:04:54,740 ‫E quindi è sempre meglio avere un posto centrale come questo 93 00:04:54,740 --> 00:04:56,560 ‫per gestire tutti i rifiuti 94 00:04:56,560 --> 00:04:59,132 ‫delle promesse come un'ultima rete di sicurezza, va bene? 95 00:04:59,132 --> 00:05:01,800 ‫Ora, se abbiamo davvero qualche problema 96 00:05:01,800 --> 00:05:04,890 ‫con la connessione al database, come abbiamo in 97 00:05:04,890 --> 00:05:07,840 ‫questo esempio, la nostra applicazione non funzionerà affatto. 98 00:05:07,840 --> 00:05:09,760 ‫E quindi tutto ciò che 99 00:05:09,760 --> 00:05:12,820 ‫possiamo davvero fare qui è chiudere la nostra applicazione, ok? 100 00:05:12,820 --> 00:05:17,053 ‫Quindi, per chiudere l'applicazione, usiamo process. Uscita. 101 00:05:18,140 --> 00:05:20,420 ‫E in realtà l'abbiamo già 102 00:05:20,420 --> 00:05:22,850 ‫usato prima in quello script in cui 103 00:05:22,850 --> 00:05:27,080 ‫abbiamo importato tutti i dati nel database dal file JSON, ricordi? 104 00:05:27,080 --> 00:05:29,660 ‫Quindi processo. exit e poi 105 00:05:29,660 --> 00:05:31,810 ‫qui dentro, possiamo effettivamente passare un codice. 106 00:05:31,810 --> 00:05:34,140 ‫E il codice zero rappresenta un 107 00:05:34,140 --> 00:05:36,800 ‫successo e uno rappresenta un'eccezione non rilevata. 108 00:05:36,800 --> 00:05:40,230 ‫E quindi è quello che di solito si usa qui, va bene? 109 00:05:40,230 --> 00:05:43,400 ‫Quindi, di solito, lo vedrai sempre così. 110 00:05:43,400 --> 00:05:46,970 ‫E aggiungiamo come un registro qui, console. log unhandler il 111 00:05:50,293 --> 00:05:51,973 ‫rifiuto, qualcosa del 112 00:05:56,020 --> 00:05:57,560 ‫genere. 113 00:05:57,560 --> 00:05:59,860 ‫Quindi vedi, mi piace molto questo, questo qui. 114 00:06:02,910 --> 00:06:04,650 ‫Lasciando che questo sia un nodo... 115 00:06:04,650 --> 00:06:06,730 ‫Non proprio utente ma il 116 00:06:06,730 --> 00:06:09,320 ‫nostro registro che stiamo chiudendo, va bene? 117 00:06:09,320 --> 00:06:12,330 ‫E così ora, vedi che l'app si è effettivamente bloccata. 118 00:06:12,330 --> 00:06:16,515 ‫E quindi è a causa di questo processo. esci da qui, va bene? 119 00:06:16,515 --> 00:06:18,860 ‫Ora, c'è solo un problema con il 120 00:06:18,860 --> 00:06:20,480 ‫modo in cui l'abbiamo 121 00:06:20,480 --> 00:06:23,430 ‫implementato in questo momento e cioè, il modo in cui 122 00:06:23,430 --> 00:06:26,990 ‫lo implementiamo qui, quindi solo processo. exit è un modo 123 00:06:26,990 --> 00:06:30,420 ‫molto brusco di terminare il programma perché questo interromperà 124 00:06:30,420 --> 00:06:34,030 ‫immediatamente tutte le richieste che sono attualmente ancora in esecuzione 125 00:06:34,030 --> 00:06:38,300 ‫o in sospeso e quindi potrebbe non essere una buona idea, ok? 126 00:06:38,300 --> 00:06:41,550 ‫E quindi, di solito, quello che facciamo è chiudere 127 00:06:41,550 --> 00:06:44,210 ‫con garbo dove prima chiudiamo il 128 00:06:44,210 --> 00:06:47,140 ‫server e solo dopo chiudiamo l'applicazione, ok? 129 00:06:47,140 --> 00:06:47,973 ‫Quindi cerchiamo... 130 00:06:47,973 --> 00:06:51,440 ‫Prima di farlo, dobbiamo salvare 131 00:06:51,440 --> 00:06:55,670 ‫il server qui sostanzialmente in una variabile, ok? 132 00:06:55,670 --> 00:06:59,650 ‫E così il risultato della chiamata app. listen è un server e 133 00:06:59,650 --> 00:07:04,650 ‫ora, su quel server, possiamo dire server. close che, come dice il 134 00:07:05,810 --> 00:07:08,400 ‫nome, chiuderà il server e poi, 135 00:07:08,400 --> 00:07:10,490 ‫dopo averlo fatto, eseguirà 136 00:07:10,490 --> 00:07:14,810 ‫questa funzione di callback che gli abbiamo passato e quindi 137 00:07:14,810 --> 00:07:16,130 ‫è solo 138 00:07:16,130 --> 00:07:19,310 ‫qui, dove quindi spegneremo il server, ok? 139 00:07:19,310 --> 00:07:22,240 ‫E così facendo, facendo server. chiudi, diamo al 140 00:07:22,240 --> 00:07:25,630 ‫server, in pratica, il tempo di completare tutte le 141 00:07:25,630 --> 00:07:28,890 ‫richieste ancora in sospeso o gestite in quel 142 00:07:28,890 --> 00:07:31,180 ‫momento, e solo dopo, il server 143 00:07:31,180 --> 00:07:32,910 ‫viene praticamente ucciso, ok? 144 00:07:32,910 --> 00:07:34,620 ‫Quindi, quando gli diamo 145 00:07:34,620 --> 00:07:37,020 ‫una cassaforte, non sembrerà esattamente lo 146 00:07:37,020 --> 00:07:39,880 ‫stesso perché, (ride) sì, siamo gli unici che 147 00:07:39,880 --> 00:07:42,850 ‫accedono davvero a questa applicazione ma nello scenario 148 00:07:42,850 --> 00:07:45,960 ‫del mondo reale, dovremmo sempre farlo così, ok ? 149 00:07:45,960 --> 00:07:48,200 ‫E, naturalmente, non è proprio 150 00:07:48,200 --> 00:07:50,520 ‫l'ideale che l'applicazione si sia bloccata, giusto? 151 00:07:50,520 --> 00:07:53,120 ‫Perché in questo momento, ovviamente, l'app non è 152 00:07:53,120 --> 00:07:55,448 ‫in esecuzione, non funziona affatto, giusto? 153 00:07:55,448 --> 00:07:59,570 ‫E così di solito, in un'app di produzione su un server web, di 154 00:07:59,570 --> 00:08:01,690 ‫solito avremo uno strumento che riavvia 155 00:08:01,690 --> 00:08:05,100 ‫l'applicazione subito dopo il crash, o anche alcune delle piattaforme 156 00:08:05,100 --> 00:08:08,120 ‫che ospitano il nodo. js lo 157 00:08:08,120 --> 00:08:11,164 ‫farà automaticamente da solo, ok? 158 00:08:11,164 --> 00:08:13,920 ‫Perché, ovviamente, non vogliamo lasciare l'applicazione sospesa in 159 00:08:13,920 --> 00:08:15,590 ‫questo modo per sempre. 160 00:08:15,590 --> 00:08:18,420 ‫Quindi neanche questo è utile, va bene? 161 00:08:18,420 --> 00:08:20,410 ‫E quindi, in pratica, è così 162 00:08:20,410 --> 00:08:22,590 ‫che gestisci le promesse rifiutate non gestite. 163 00:08:22,590 --> 00:08:25,130 ‫Quindi, di nuovo, in pratica, stiamo ascoltando questo 164 00:08:25,130 --> 00:08:27,930 ‫evento di rifiuto non gestito, che ci consente quindi 165 00:08:27,930 --> 00:08:30,100 ‫di gestire tutti gli errori 166 00:08:30,100 --> 00:08:32,280 ‫che si verificano nel codice asincrono 167 00:08:32,280 --> 00:08:34,470 ‫che non sono stati gestiti in precedenza. 168 00:08:34,470 --> 00:08:38,050 ‫Ma ora, potresti chiedere, che dire del codice sincrono? 169 00:08:38,050 --> 00:08:40,110 ‫Dove lo gestiremo? 170 00:08:40,110 --> 00:08:43,020 ‫E la risposta si trova, come puoi immaginare, 171 00:08:43,020 --> 00:08:44,523 ‫nel prossimo video.