‫Istruttore: Va bene!
‫E ora, per finire questa
‫sezione, impariamo come catturare le eccezioni non rilevate.
‫Ma cosa sono esattamente le eccezioni non rilevate?
‫Bene, tutti gli errori, o chiamiamoli anche bug, che si
‫verificano nel nostro codice sincrono
‫ma non vengono gestiti da nessuna parte sono chiamati eccezioni non rilevate.
‫E come prima, proprio come con i rifiuti non gestiti, abbiamo
‫anche un modo per gestire le eccezioni non rilevate.
‫Quindi lascia che ti mostri
‫rapidamente un esempio di un'eccezione non rilevata.
‫Quindi facciamo semplicemente finta che stiamo cercando
‫di consolare. registra qualcosa che non esiste.
‫E così subito, otteniamo questo errore qui, x non è definito, e
‫quindi per impostazione predefinita, otteniamo l'intera traccia dello stack
‫qui stampata sulla console.
‫Tutto bene.
‫E ora, per risolvere questo problema, è molto simile a fare i
‫rifiuti non gestiti.
‫Quindi, di nuovo, stiamo ascoltando un evento,
‫questa volta si chiama uncaughtException.
‫E ovviamente deve essere tra virgolette.
‫E poi, proprio come prima, passiamo alla nostra funzione di callback.
‫Bene.
‫E ora in realtà quello che stiamo facendo qui è molto simile
‫a quello che abbiamo fatto qui.
‫Quindi vogliamo bloccare l'errore sulla console
‫in modo che venga visualizzato nei log del nostro server, ok?
‫Quindi, dandoci un modo per risolvere il problema.
‫E poi vogliamo chiudere con garbo il server.
‫Quindi, in realtà qui
‫voglio stampare l'intero errore sulla console
‫e non solo il messaggio, ok?
‫E cambiamo anche l'ordine qui, ma
‫questo è tutto.
‫Quindi il resto è lo stesso.
‫Ed
‫ecco ovviamente un'ECCEZIONE NON CATTURATA!
‫Ora potrei rifattorizzare questo qui in una bella
‫funzione, ma manteniamolo così, va bene?
‫Ok, ora ripetiamo questo.
‫E quindi diamo un'occhiata a ciò che abbiamo qui.
‫E infatti, ora vediamo ECCEZIONE NON CATTURATA!
‫Chiudere.
‫Tutto ok?
‫E in realtà questo stampa di nuovo l'intero stack
‫sulla console, ma non lo voglio davvero.
‫Non mi piace.
‫Quindi torniamo a quello che abbiamo avuto qui.
‫Quindi sbaglia. nome e poi sbagliare. Messaggio.
‫Ok, quindi ora
‫abbiamo il ReferenceError che x non è definito, ok?
‫E mettiamo lo stesso qui.
‫Quindi, proprio come prima.
‫Tutto bene.
‫E questo è tutto
‫ciò che serve per catturare eccezioni non rilevate.
‫Ora, mentre qui nel rifiuto non gestito, l'arresto
‫anomalo dell'applicazione come abbiamo fatto qui è facoltativo, quando
‫c'è un'eccezione non rilevata, abbiamo davvero,
‫davvero bisogno di arrestare l'applicazione perché dopo che si è
‫verificata un'eccezione non rilevata, l'intero processo del nodo
‫è in un
‫modo così -chiamato stato immondo, va bene?
‫E quindi per risolvere il problema, il processo deve terminare
‫e poi essere riavviato, ok?
‫E ancora,
‫in produzione, dovremmo avere uno
‫strumento che riavvierà l'applicazione dopo l'arresto anomalo.
‫E molti servizi di hosting lo fanno già fuori
‫dagli schemi, va bene?
‫Quindi, in modo completamente automatico senza che
‫noi dobbiamo fare nulla.
‫Ora, nel nodo. js, non è
‫proprio una buona pratica affidarsi ciecamente a questi due gestori di
‫errori che abbiamo appena implementato qui, ok?
‫Quindi idealmente gli errori dovrebbero essere gestiti
‫proprio dove si verificano.
‫Quindi, per esempio, nel problema di connessione al database, dovremmo ovviamente
‫aggiungere un gestore di cattura lì e
‫non semplicemente fare affidamento
‫sul callback di rifiuto non gestito che abbiamo qui, ok?
‫E alcune persone dicono anche che non dovremmo usarli affatto, ma non
‫sono d'accordo con questo.
‫Penso che come rete di sicurezza, diciamo,
‫possano essere molto utili e avere un ruolo nella nostra applicazione.
‫Ora in realtà questo
‫gestore dovrebbe essere in cima al nostro codice, ok?
‫O almeno prima che qualsiasi altro codice venga realmente eseguito.
‫Perché guarda cosa succede se sposto questa riga di codice qui
‫prima di questo gestore.
‫Quindi se lo metto qui, ad esempio,
‫e poi gli do un
‫salvataggio, allora in realtà
‫vedi che il nostro gestore non rileva questa eccezione, quindi questo errore qui, giusto?
‫E questo perché solo qui alla
‫fine iniziamo effettivamente ad ascoltare un'eccezione non rilevata.
‫Ma in questo caso, l'eccezione non
‫rilevata si verifica prima ancora che ascoltiamo quell'evento.
‫E quindi, non abbiamo modo di prenderlo, giusto?
‫E quindi dovremmo idealmente metterlo qui, proprio in alto, di nuovo prima che
‫venga eseguito qualsiasi altro codice.
‫Soprattutto quello nella nostra applicazione.
‫Quindi mettiamolo in realtà proprio qui.
‫Ora il problema qui
‫sarà che il server non è definito a questo punto.
‫Ma questo non è
‫un problema, perché in realtà non abbiamo
‫affatto bisogno del server qui, va bene?
‫E questo perché
‫questi errori, quindi queste eccezioni non
‫rilevate, non si verificheranno in modo asincrono.
‫Quindi in realtà non avranno
‫nulla a che fare con il server.
‫Quindi non abbiamo affatto bisogno di questo qui.
‫Possiamo semplicemente salvarlo qui,
‫quindi ora lo abbiamo prima di richiedere effettivamente la
‫nostra applicazione principale.
‫E quindi se ora abbiamo
‫un errore, proviamolo prima qui, così
‫vedrai che ora
‫siamo tornati a catturarlo effettivamente nel nostro gestore di errori.
‫Ma se ora avessimo questo codice, ad esempio all'interno di app. js, diciamo, non ha molta
‫importanza, diciamo solo che è qui, e se
‫ora eseguiamo
‫questo, beh, allora vedi che stiamo
‫ancora catturando quell'eccezione nel nostro
‫gestore degli errori, che prima non sarebbe il caso.
‫Tutto ok?
‫E ora, solo per fare
‫un esperimento, cosa ne pensi se inserissimo questo
‫codice proprio qui in questa funzione middleware?
‫Cosa pensi che accadrà
‫quando salviamo questo file ora?
‫Quindi x non è ancora definito da nessuna parte,
‫ma diamo un'occhiata a cosa succede
‫quando eseguiamo questo codice.
‫E così ora in realtà non abbiamo errori.
‫O in realtà lo facciamo,
‫ma è solo a causa del nostro rifiuto non
‫gestito, dovuto al fatto che la
‫nostra password qui è ancora sbagliata.
‫Quindi, se lo salviamo e lo salviamo di
‫nuovo, non dovresti vedere alcun errore.
‫E infatti, non lo facciamo.
‫E perché?
‫Bene, è perché questa funzione middleware qui ovviamente
‫viene chiamata solo
‫non appena c'è effettivamente una richiesta, giusto?
‫E quindi vediamo cosa succede quando facciamo una richiesta.
‫E quindi facciamo una richiesta Ottieni tutti i tour.
‫E aspettiamo.
‫E qui otteniamo un "Qualcosa è andato molto storto! " messaggio di
‫errore con la 500, ed
‫è anche perché siamo
‫ancora in modalità produzione, ok?
‫Ma comunque, ricevere questo messaggio qui, ricorda, significa
‫che abbiamo un errore non operativo qui.
‫Quindi fondamentalmente un errore che non ci siamo creati noi.
‫E quindi, proprio questo, ora entriamo
‫qui nel nostro errorController, andiamo proprio qui, giusto?
‫Quindi in questo altro ramo qui nella funzione sendErrorProd.
‫E in effetti
‫vedi l'errore anche qui nella console, ok?
‫Ed è quello che succede quando
‫c'è un errore all'interno di qualsiasi middleware Express, giusto?
‫Quindi Express, quando si verifica
‫un errore, passerà automaticamente al middleware di gestione degli
‫errori con quell'errore, ok?
‫Ed ecco perché quando
‫riceviamo un errore qui in una
‫qualsiasi delle nostre funzioni middleware, andrà immediatamente qui in questo gestore, ok?
‫E poiché
‫siamo in produzione, inserirà questo
‫blocco qui, ma poiché non è
‫un CastError, e non questo errore, e
‫non un ValidationError, non appena l'errore viene effettivamente
‫inviato, proprio qui, inseriamo questo blocco .
‫E ancora, ecco perché inviamo questo errore generico, ok?
‫Ora usciamo effettivamente da questa modalità qui
‫e torniamo al nostro normale avvio di npm.
‫E quindi in questo momento, il nostro errore verrà inviato in questo modo, giusto?
‫Quindi inviare errore di sviluppo ci darà tutti i
‫dettagli sull'errore che si sta verificando.
‫E così ora effettivamente otteniamo ReferenceError: x non è definito.
‫Bene?
‫Quindi nell'app. js, riga 21.
‫E così, la riga 21 è dov'è,
‫ma liberiamocene.
‫Volevo solo mostrartelo.
‫Bene?
‫Ad ogni modo, con questo, chiudiamo effettivamente la
‫nostra sezione di gestione degli errori.
‫E potrebbe esserci un intero corso sulla gestione degli
‫errori con Node ed Express, perché è davvero
‫un argomento follemente complesso.
‫Ma, in questa sezione, impari gli elementi
‫essenziali che devi sapere per iniziare
‫davvero a creare applicazioni straordinarie.