‫Istruttore: In questo video, parliamo di
‫qualcosa che abbiamo in node. js ha chiamato rifiuti non
‫gestiti e quindi impara come possiamo effettivamente gestirli.
‫Quindi, a questo punto, abbiamo gestito con successo
‫gli errori nella nostra
‫applicazione express passando gli errori operativi asincroni in un
‫middleware di gestione degli errori globale.
‫Questo, quindi, invia messaggi di errore rilevanti al client
‫a seconda del tipo di errore che si è verificato, giusto?
‫Tuttavia, potrebbero verificarsi errori anche al di fuori di express e
‫un buon esempio di ciò nella nostra applicazione corrente è
‫la connessione al database mongodb.
‫Quindi immagina che il database sia inattivo per qualche motivo
‫o per qualche motivo, non possiamo accedere.
‫E in tal caso, ci sono
‫anche errori che dobbiamo gestire.
‫Ma non si sono verificati all'interno della nostra applicazione express
‫e quindi, ovviamente, il nostro gestore di errori che
‫abbiamo implementato non rileverà questi errori, giusto?
‫E quindi, solo per testare cosa succede,
‫andiamo avanti e cambiamo la nostra password mongodb, ok?
‫Perché in questo modo
‫non saremo in grado di connetterci al database, giusto?
‫E quindi dovremmo ricevere un qualche tipo di
‫errore, quindi andiamo qui nel nostro
‫file del server e salviamolo per ricaricare il nostro
‫server, aumentiamolo qui, e infatti,
‫qui abbiamo un rifiuto della promessa non gestito.
‫E quindi questo è in realtà l'argomento di questo video.
‫Quindi un rifiuto di una promessa non gestita significa che da qualche parte
‫nel nostro codice c'è una promessa che è stata rifiutata.
‫Ma quel rifiuto non è stato gestito da nessuna parte, va bene?
‫E qui sotto, vedi anche un avviso di deprecazione che
‫dice che in futuro i rifiuti non
‫gestiti usciranno semplicemente dal programma del nodo in esecuzione, che
‫potrebbe non essere sempre quello che vuoi, ok?
‫Quindi risolviamo questo problema e liberiamoci
‫di questo rifiuto non gestito della promessa.
‫Ora, in questo semplice esempio
‫qui, sarebbe in
‫realtà abbastanza facile gestire quel rifiuto, giusto?
‫Tutto quello che dovremo fare sarebbe venire qui
‫a questo pezzo di codice in cui la nostra connessione è effettivamente stabilita
‫e quindi aggiungere un gestore di cattura lì, giusto?
‫Quindi un po' così, e poi qui
‫dentro, potremmo gestire quel rifiuto
‫e quindi non otterremmo più questo errore.
‫Lascia che te lo mostri velocemente.
‫Quindi riprova.
‫E così ora, ottieni un errore che è ovviamente il
‫risultato di questo registro qui, ma
‫ovviamente non otteniamo alcun rifiuto non gestito della
‫promessa, di nuovo, perché in realtà l'abbiamo gestito qui, va bene?
‫Quindi questo funzionerebbe, ovviamente, ma voglio davvero mostrarti come gestire
‫globalmente le promesse rifiutate non gestite, perché in un'applicazione
‫più grande, può diventare un po' più difficile
‫tenere sempre traccia di tutte le promesse che potrebbero
‫essere rifiutate in alcuni punto, ok?
‫E così ad un certo punto, potresti avere
‫qualche rifiuto non gestito della promessa da qualche parte e quindi lascia
‫che ti mostri come affrontarlo a livello globale in pratica.
‫E quindi ora impariamo come gestire i rifiuti non gestiti e
‫lo faremo proprio qui.
‫E allora ricordate come in una delle prime sezioni
‫del corso abbiamo parlato di eventi
‫e ascoltatori di eventi, giusto?
‫E quindi ora è il momento di usare effettivamente quella conoscenza.
‫Quindi, ogni volta che c'è un rifiuto
‫non gestito da qualche parte nella nostra applicazione,
‫l'oggetto processo emetterà un oggetto chiamato rifiuto non gestito
‫e quindi possiamo iscriverci a quell'evento proprio in questo modo.
‫Quindi processo. on, ricorda, e poi
‫il nome dell'evento, il rifiuto non gestito, e
‫quindi la funzione
‫di callback qui riceve un errore, quindi andiamo
‫avanti e registriamo l'errore nella console.
‫Quindi usiamo err. nome ed err. Messaggio.
‫Quindi questi sono una specie di default che
‫abbiamo su tutti gli errori in node. js, va bene?
‫Ok, e dopo aver salvato, abbiamo già qui
‫sotto il nome dell'errore e anche il messaggio di errore.
‫Quindi pessima autenticazione perché, ovviamente, abbiamo la
‫password sbagliata.
‫E quindi proprio ora, il rifiuto della promessa non
‫gestita ora viene effettivamente gestito.
‫E ovviamente, non solo quello di questa connessione fallita, ma
‫qualsiasi altro rifiuto della promessa che potremmo non
‫rilevare da qualche parte nell'applicazione viene gestito qui in questa finale,
‫chiamiamola rete di sicurezza, va bene?
‫Quindi dobbiamo sempre presumere che noi come
‫programmatori faremo errori.
‫E quindi è sempre meglio avere un posto centrale come questo
‫per gestire tutti i rifiuti
‫delle promesse come un'ultima rete di sicurezza, va bene?
‫Ora, se abbiamo davvero qualche problema
‫con la connessione al database, come abbiamo in
‫questo esempio, la nostra applicazione non funzionerà affatto.
‫E quindi tutto ciò che
‫possiamo davvero fare qui è chiudere la nostra applicazione, ok?
‫Quindi, per chiudere l'applicazione, usiamo process. Uscita.
‫E in realtà l'abbiamo già
‫usato prima in quello script in cui
‫abbiamo importato tutti i dati nel database dal file JSON, ricordi?
‫Quindi processo. exit e poi
‫qui dentro, possiamo effettivamente passare un codice.
‫E il codice zero rappresenta un
‫successo e uno rappresenta un'eccezione non rilevata.
‫E quindi è quello che di solito si usa qui, va bene?
‫Quindi, di solito, lo vedrai sempre così.
‫E aggiungiamo come un registro qui, console. log unhandler il
‫rifiuto, qualcosa del
‫genere.
‫Quindi vedi, mi piace molto questo, questo qui.
‫Lasciando che questo sia un nodo...
‫Non proprio utente ma il
‫nostro registro che stiamo chiudendo, va bene?
‫E così ora, vedi che l'app si è effettivamente bloccata.
‫E quindi è a causa di questo processo. esci da qui, va bene?
‫Ora, c'è solo un problema con il
‫modo in cui l'abbiamo
‫implementato in questo momento e cioè, il modo in cui
‫lo implementiamo qui, quindi solo processo. exit è un modo
‫molto brusco di terminare il programma perché questo interromperà
‫immediatamente tutte le richieste che sono attualmente ancora in esecuzione
‫o in sospeso e quindi potrebbe non essere una buona idea, ok?
‫E quindi, di solito, quello che facciamo è chiudere
‫con garbo dove prima chiudiamo il
‫server e solo dopo chiudiamo l'applicazione, ok?
‫Quindi cerchiamo...
‫Prima di farlo, dobbiamo salvare
‫il server qui sostanzialmente in una variabile, ok?
‫E così il risultato della chiamata app. listen è un server e
‫ora, su quel server, possiamo dire server. close che, come dice il
‫nome, chiuderà il server e poi,
‫dopo averlo fatto, eseguirà
‫questa funzione di callback che gli abbiamo passato e quindi
‫è solo
‫qui, dove quindi spegneremo il server, ok?
‫E così facendo, facendo server. chiudi, diamo al
‫server, in pratica, il tempo di completare tutte le
‫richieste ancora in sospeso o gestite in quel
‫momento, e solo dopo, il server
‫viene praticamente ucciso, ok?
‫Quindi, quando gli diamo
‫una cassaforte, non sembrerà esattamente lo
‫stesso perché, (ride) sì, siamo gli unici che
‫accedono davvero a questa applicazione ma nello scenario
‫del mondo reale, dovremmo sempre farlo così, ok ?
‫E, naturalmente, non è proprio
‫l'ideale che l'applicazione si sia bloccata, giusto?
‫Perché in questo momento, ovviamente, l'app non è
‫in esecuzione, non funziona affatto, giusto?
‫E così di solito, in un'app di produzione su un server web, di
‫solito avremo uno strumento che riavvia
‫l'applicazione subito dopo il crash, o anche alcune delle piattaforme
‫che ospitano il nodo. js lo
‫farà automaticamente da solo, ok?
‫Perché, ovviamente, non vogliamo lasciare l'applicazione sospesa in
‫questo modo per sempre.
‫Quindi neanche questo è utile, va bene?
‫E quindi, in pratica, è così
‫che gestisci le promesse rifiutate non gestite.
‫Quindi, di nuovo, in pratica, stiamo ascoltando questo
‫evento di rifiuto non gestito, che ci consente quindi
‫di gestire tutti gli errori
‫che si verificano nel codice asincrono
‫che non sono stati gestiti in precedenza.
‫Ma ora, potresti chiedere, che dire del codice sincrono?
‫Dove lo gestiremo?
‫E la risposta si trova, come puoi immaginare,
‫nel prossimo video.