‫Docente: Salve.
‫Rendiamo ora alcune belle pagine di errore ai nostri utenti.
‫E quindi, per iniziare, creiamo prima un errore.
‫Quindi apriamo questo tour qui.
‫No, non voglio tradurre.
‫E ora aggiungiamo semplicemente qualcosa a questo registro qui, in
‫modo che, ovviamente, non venga trovato.
‫Giusto, quindi ecco come appare un errore a
‫questo punto.
‫Quindi, semplicemente, tutto questo
‫JSON qui, proprio come sembrerebbe in Postman.
‫Quindi abbiamo già visto questo tipo di errore qui.
‫E quindi, ora risolviamolo.
‫Ma prima dobbiamo effettivamente correggere questo particolare errore.
‫Quindi in questo momento
‫otteniamo, non possiamo leggere il nome della proprietà di null in getTour.
‫Bene.
‫E quindi questo è qui nel nostro controller di visualizzazioni, getTour.
‫E quindi qui, non abbiamo alcuna gestione degli
‫errori nel caso in cui non ci sia un tour, giusto?
‫Quindi lo abbiamo in tutti gli altri nostri gestori di
‫rotte, ma in questo non ce l'abbiamo ancora.
‫Quindi aggiungiamolo.
‫Quindi, se non c'è un tour, torna e vai
‫al middleware successivo con un nuovo errore dell'app.
‫E probabilmente non è ancora qui.
‫E no infatti, non lo è.
‫Quindi cost.
‫AppError è uguale a.
‫Bene.
‫Errore qui ovviamente.
‫E poi diciamo che
‫non c'è nessun tour con quel nome.
‫E poi è un 404 per non trovato.
‫Bene?
‫Quindi proviamo di nuovo.
‫E così ora dovremmo ottenere un errore molto più carino.
‫E infatti, ne otteniamo uno.
‫Quindi 404.
‫E tieni presente che questo ora è un errore operativo.
‫Quindi un errore che sappiamo di aver creato noi stessi fondamentalmente.
‫E quindi, proprio come prima, sarà importante per la nostra
‫strategia di gestione degli errori.
‫Quindi, parliamone davvero.
‫E quindi qui abbiamo finito.
‫E ora nel nostro controller
‫degli errori, abbiamo, ricordiamo, due funzioni che rimandano
‫gli errori al client.
‫Quindi abbiamo questo qui per lo sviluppo
‫e questo per la produzione.
‫Quindi, in produzione,
‫distinguiamo tra errori operativi e altri errori sconosciuti.
‫Destra?
‫E quindi è proprio quello di cui abbiamo appena parlato prima.
‫Quindi, per gli errori che
‫conosciamo, inviamo il messaggio di errore reale perché possiamo
‫essere sicuri che non sarà un errore
‫dall'aspetto strano proveniente
‫da qualche parte da express o note
‫o qualcosa del genere.
‫Mentre, d'altra parte, quando si tratta di un errore sconosciuto,
‫beh, allora non vogliamo far trapelare i dettagli dell'errore.
‫E quindi ora in questo caso, con
‫il sito Web renderizzato, utilizzeremo effettivamente la stessa strategia.
‫Ora, quello che farò
‫è semplicemente aggiungere il rendering di una pagina di
‫errore a ciascuna di queste funzioni.
‫E fondamentalmente, quello che farò
‫è verificare se l'URL inizia con l'API slash.
‫E quindi in tal caso, inviamo questo tipo di errore, giusto.
‫Ma se l'URL non inizia con l'API, beh in quel caso, significa
‫che vogliamo rendere una pagina di errore
‫come un sito web renderizzato, ok?
‫Proprio come abbiamo fatto in questa sezione.
‫Ad ogni modo, ora implementiamolo.
‫Quindi, possiamo usare l'URL originale request dot.
‫E probabilmente l'abbiamo usato prima.
‫Bene?
‫Quindi l'URL originale è fondamentalmente l'intero URL ma
‫non con l'host.
‫Così sembra, esattamente come il percorso.
‫E così di nuovo, quando raggiungiamo il
‫nostro URL, beh, allora quel percorso inizia con l'API slash.
‫E così ora possiamo testarlo.
‫Quindi possiamo usare una funzione JavaScript chiamata startWith.
‫Quindi una funzione disponibile per le stringhe.
‫E poi prova se inizia con l'API slash.
‫Destra?
‫E quindi se lo fa, allora questo è ciò che vogliamo fare.
‫Quindi invia semplicemente l'errore come JSON.
‫Ma in caso contrario, allora in realtà vogliamo rendere un errore.
‫Quindi è ancora res. stato.
‫E anche a statusCode.
‫Ma qui dentro è effettivamente renderizzato.
‫Quindi otteniamo il nome del modello
‫e creeremo questo modello in un secondo,
‫ma si chiamerà errore.
‫E poi i dati che vogliamo inviare lì
‫per ora sono solo il titolo.
‫E aggiungerò altre cose una
‫volta che il modello sarà effettivamente terminato.
‫Quindi qualcosa è andato storto sarà il titolo di
‫questa pagina di errore.
‫Bene?
‫Oh, in realtà non
‫abbiamo accesso alla variabile request qui.
‫E la sua funzione.
‫E quindi aggiungiamolo.
‫Richiedi qui.
‫E ne avremo bisogno anche qui.
‫Questo.
‫E quindi aggiungiamolo anche qui.
‫Quindi proprio qui.
‫Bene.
‫Quindi, ora abbiamo effettivamente bisogno di creare questa pagina,
‫o questo modello, chiamato errore.
‫E ancora una volta, ho già un semplice modello per questo.
‫Quindi è in dev-data, templates ed errorTemplate.
‫Bene?
‫Quindi copiamo questo.
‫E poi crea una vista per quello.
‫errore. carlino.
‫Bene.
‫E quindi qui abbiamo un semplice h2 che dice, uh
‫oh, qualcosa è andato storto.
‫Poi (ride) ci sono degli emoji divertenti.
‫Non sono molto divertenti.
‫E poi ecco che vogliamo poter passare anche in un messaggio.
‫Bene?
‫Quindi aggiungiamo questo uguale a msg, solo una scorciatoia per messaggio.
‫Bene?
‫Ed è proprio così.
‫Quindi chiudiamolo e trasmettiamo quel messaggio.
‫Quindi msg è quindi impostato.
‫E impostiamolo davvero sul messaggio di errore.
‫Bene?
‫E lo stiamo facendo qui perché siamo in fase di sviluppo.
‫Quindi tienilo a mente.
‫Aggiungiamo anche alcuni commenti qui.
‫API.
‫Mettiamolo qui.
‫Il sito web reso.
‫Quindi lo stiamo facendo in questo modo, con un messaggio
‫di errore, di nuovo
‫perché in fase di sviluppo non importa se trapeliamo tutti i
‫dettagli dell'errore sulla nostra pagina, giusto?
‫Perché nessuno lo vedrà davvero dal momento che, sì, siamo
‫in fase di sviluppo.
‫Quindi dovrebbe funzionare ora.
‫Quindi tutto ciò che dovremmo fare ora è ricaricare questa pagina.
‫Ma ora qui c'è qualcosa che non va.
‫Quindi dice che non ha inviato alcun dato.
‫Quindi torniamo qui.
‫Bene, come primo problema che vedo
‫qui, dovrei avere il codice di stato e non solo lo stato.
‫Questo è tutto per verificare se abbiamo qualche errore qui.
‫O si.
‫In realtà ci sono errori.
‫Quindi, in realtà era il codice di stato non valido.
‫Quindi qui dovrebbe essere il codice.
‫Diamo un altro salvataggio.
‫Ricaricalo.
‫E ora otteniamo qualche pagina di errore qui.
‫Beh, non è davvero formattato.
‫Tuttavia, ha il titolo e, cosa più
‫importante, ha questo messaggio che abbiamo appena trasmesso.
‫Quindi non c'è nessun tour con quel nome.
‫E questo viene esattamente dal nostro controller di visualizzazioni.
‫Quindi proprio da qui.
‫Quindi ricorda quella logica in cui creiamo un errore qui che
‫viene poi passato al nostro errore globale
‫e al middleware Lint.
‫Destra?
‫E quindi è quello che raccoglierà
‫questi errori e li invierà al cliente.
‫Ora, nel nostro caso, riceviamo questo
‫errore perché qui nel nostro modello abbiamo ancora
‫dimenticato di fare qualcosa.
‫Che è semplicemente estendere, ovviamente, il nostro modello principale.
‫Destra?
‫Quindi dobbiamo dire estendere al modello di base.
‫E poi, come sempre, crea quel blocco qui.
‫Quindi blocca il contenuto.
‫E poi tutto questo deve essere lì dentro.
‫E quindi fondamentalmente qui stiamo
‫facendo esattamente la stessa cosa che abbiamo fatto in tutti gli altri modelli.
‫Quindi fondamentalmente iniettando questo contenuto
‫qui nel blog dei contenuti nel modello di base.
‫Quindi, se lo ricarichiamo ora, finalmente sembrerà come previsto.
‫Bene?
‫E ora, se abbiamo effettivamente avuto qualche errore nel nostro
‫codice, e quindi diciamo di nuovo
‫che non abbiamo questa gestione degli errori
‫qui, allora ovviamente l'intero errore è trapelato al client.
‫Quindi non è possibile leggere il nome della proprietà di null.
‫E, naturalmente, non vogliamo che i visitatori del nostro
‫sito web ricevano questo tipo di errore, giusto?
‫Nessuno capirebbe davvero cosa significa.
‫E così nel nostro gestore degli errori di produzione,
‫ora ce ne occupiamo noi.
‫Quindi quaggiù nel nostro controller di
‫errore, ora applichiamo la stessa logica che abbiamo qui.
‫Quindi testiamo se stiamo attualmente gestendo l'API o meno.
‫E naturalmente potrebbero esserci modi più eleganti
‫per farlo.
‫Ad esempio, potresti avere un middleware di
‫gestione degli errori completamente separato solo per l'API
‫e uno per il sito Web renderizzato, giusto?
‫Ma ancora una volta, voglio solo mantenerlo un po' semplice qui.
‫Bene?
‫Quindi, in questo caso, questo è davvero il mio obiettivo principale.
‫Bene.
‫Selezioniamo tutto questo.
‫Oh, cosa è successo lì?
‫Ah, ci siamo.
‫Bene.
‫Quindi questo è per l'API.
‫E ora avremo effettivamente qualcosa di molto simile.
‫Quindi questo è, di nuovo, per il sito web renderizzato.
‫Chiamiamolo B qui e A per questo.
‫Quindi, solo per separarlo un po' meglio.
‫Quindi abbiamo e poi B quaggiù.
‫Comunque, questo sarà un po' simile a questo.
‫Quindi, se abbiamo un errore operativo, in pratica la
‫pagina di
‫errore dovrebbe apparire come prima.
‫Ma nel caso si tratti di un errore di
‫programmazione o sconosciuto, allora non vogliamo il messaggio completo, ma
‫solo un messaggio molto generico.
‫Quindi qualcosa come per favore riprova più tardi.
‫Bene?
‫Ora vediamo che tipo di errore otteniamo qui.
‫E a quanto pare, otteniamo qualcosa chiamato
‫una dichiarazione if solitaria qui.
‫Destra.
‫Quindi sì, Lint non vuole
‫che abbiamo solo un if all'interno di un blocco else.
‫E sono d'accordo che non
‫è una bella pratica di programmazione.
‫E quindi, in effetti, risolviamo il
‫problema sbarazzandoci di quest'altro qui.
‫Dagli un salvataggio.
‫E poi quell'errore è sparito.
‫Ma ora dobbiamo assicurarci che questo qui termini
‫davvero il ciclo di risposta alla richiesta.
‫E quindi dobbiamo tornare qui e anche qui.
‫Bene.
‫Ora, un altro errore ESLint, altro non necessario dopo un ritorno.
‫E infatti, anche questo è vero.
‫E in realtà ho seguito questa
‫regola durante tutto il corso perché mi piace come
‫pratica di programmazione.
‫E quindi, sì, allora liberiamoci di quest'altro.
‫Credo davvero, e ci credo da molto tempo, che
‫sia molto più bello senza queste affermazioni if else, ma invece
‫solo con un if, come questo qui, e poi includi
‫l'altro al di fuori di quello.
‫Ok, questo è quello che abbiamo qui adesso.
‫Mettiamo anche A e B qui.
‫B.
‫E infatti, facciamo la stessa identica cosa qui.
‫Quindi torna.
‫Restituisci anche questo.
‫Poi qui, anche A e B.
‫Quindi, in effetti, mi sembra più pulito.
‫Ora abbiamo A qui e A qui
‫di nuovo, ma, beh, non importa a questo punto.
‫Bene.
‫Quindi torna qui.
‫Torna qui.
‫E prima che mi urli contro, rimuoviamo questo.
‫E così è di nuovo meglio.
‫Quindi mettilo qui.
‫E dovrebbe essere così.
‫Bene?
‫Facciamo solo per
‫completezza di copiare questo commento anche qui.
‫E poi chiamalo di nuovo B.
‫Bene.
‫Perfetto.
‫In realtà copiamo anche questo qui
‫nella funzione di sviluppo.
‫Perché in questo momento, una volta restituito
‫l'errore, non abbiamo davvero modo di vedere l'errore completo.
‫Va bene, quindi, sbarazzati di questo per renderlo più visibile.
‫E adesso è bellissimo.
‫Bene.
‫Quindi ora chiudiamolo qui
‫in modo da poter avviare la nostra applicazione di produzione.
‫Quindi fondamentalmente lo eseguo ora in produzione.
‫E abbiamo uno script per
‫quello che si chiama npm run start production.
‫Bene?
‫Quindi, se lo testiamo ora,
‫non dovremmo più vedere questa stringa qui, ricordi?
‫Perché a questo punto, non abbiamo alcuna gestione degli errori
‫per un nome di tour non valido come questo.
‫Bene?
‫Destra?
‫Dato che siamo
‫in produzione e non si tratta di
‫un errore operativo, beh, non vogliamo vederlo.
‫E quindi è quello che abbiamo appena codificato prima.
‫E quindi, in effetti, questo è il messaggio di errore più generico.
‫Destra?
‫Ma se poi lo rimettiamo qui nel controller delle viste, quindi
‫se reinseriamo questa gestione degli
‫errori, allora ovviamente, poiché questo qui sarà
‫ora un errore operativo, allora otterremo ovviamente quella
‫stringa di errore.
‫Perché è sempre
‫bello mostrare un messaggio amichevole all'utente.
‫Ma come hai visto, in realtà non è successo.
‫Allora perché?
‫Bene, siamo nell'errore di produzione.
‫Siamo al sito renderizzato.
‫E infatti, abbiamo un errore operativo.
‫E così ...
‫Abbiamo questo a posto.
‫E quindi, in effetti, dovrebbe funzionare come ci aspettavamo.
‫Bene, proviamo a registrare sulla console il messaggio
‫del punto di errore
‫solo per vedere se a questo punto l'abbiamo effettivamente ottenuto.
‫Bene.
‫Ricarica questo ragazzo.
‫E quindi c'è l'errore.
‫Ma comunque, è molto strano.
‫Quindi questo ha effettivamente registrato l'intero errore.
‫Molto strano.
‫Perché per qualche motivo, anche il messaggio non è lì.
‫Quindi eseguiamolo di nuovo in fase di sviluppo.
‫Quindi npm inizia.
‫Bene.
‫E qui, per qualche ragione, ottiene l'accesso a questo messaggio.
‫Ciò significa che nel nostro controller delle viste,
‫abbiamo effettivamente impostato correttamente quel messaggio.
‫Eseguilo di nuovo in produzione.
‫Quindi questo è il genere di cose che non ci piacciono, giusto?
‫Quindi diamo un'occhiata a dove viene effettivamente creato il
‫nostro errore di produzione.
‫E questo è qui.
‫Quindi questo oggetto errore che stiamo usando qui in
‫produzione è una copia di questo errore, giusto?
‫Quindi quello che sta entrando in questo middleware.
‫E quindi diamo un'occhiata a entrambi nella
‫console.
‫Quindi messaggio di errore.
‫E poi anche il messaggio di errore.
‫Quindi fallo di nuovo.
‫Bene.
‫Quindi vediamo quell'errore, quindi
‫quello che sta entrando direttamente nella nostra funzione
‫middleware, ha davvero il messaggio.
‫Ma poi quello che copiamo, quindi errore, per qualche
‫motivo non lo fa.
‫E quindi questo trucco che stiamo facendo
‫qui, per qualche motivo non copia il messaggio con esso,
‫va bene?
‫E quindi facciamo una rapida soluzione a questo.
‫E diciamo che il messaggio di punto di errore è uguale a messaggio di punto di errore.
‫Bene?
‫E quindi dovrebbe risolverlo, si spera.
‫Va bene.
‫Eccoci qui.
‫Destra.
‫Quindi ora vedi che sono davvero la stessa cosa.
‫E quindi questo era il problema.
‫Bene?
‫Quindi senza questo, in
‫realtà tutti gli errori non funzionerebbero correttamente.
‫Quindi, se lo pubblichiamo qui e
‫proviamo ad accedere, ad esempio, allora admin@natours. io.
‫Quindi vedi, qui otteniamo anche un errore non definito.
‫Bene.
‫E questo è di nuovo perché siamo
‫in produzione e il nostro oggetto errore non ha copiato correttamente il messaggio.
‫Non sono sicuro del motivo per cui non
‫l'ho catturato quando lo stavamo effettivamente implementando.
‫Ma forse non l'ho testato in modo abbastanza approfondito.
‫Bene?
‫E comunque, se lo proviamo
‫ora, ora otteniamo il messaggio di errore corretto che
‫ci aspettiamo.
‫Bene.
‫Grande.
‫Quindi è risolto.
‫E questo conclude questo video.
‫Quindi, in
‫conclusione, ora abbiamo una strategia di
‫gestione degli errori che funziona per lo sviluppo, come prima, e
‫anche per la produzione.
‫E poi in ognuno di essi, abbiamo fondamentalmente due rami.
‫Uno invia il messaggio di errore per l'API,
‫che è esattamente quello che avevamo
‫prima, e ora abbiamo anche una specie di gestore per
‫il sito Web renderizzato.
‫E quindi in tal caso, rendiamo il nostro modello di errore.
‫Quindi in produzione, distinguiamo anche
‫tra sito Web renderizzato e API.
‫E poi come
‫prima, all'interno di ognuno di questi
‫rami, distinguiamo poi anche tra gli
‫errori di operazione e gli errori sconosciuti.
‫Così operativo e sconosciuto.
‫E poi interni resi, anch'essi operativi e sconosciuti.
‫E così per il sito
‫Web reso, se abbiamo un errore operativo, quindi affidabile,
‫inviamo il nostro messaggio di errore attendibile.
‫Ma nel caso in cui non
‫ci fidiamo dell'errore,
‫quindi quando non lo sappiamo, inviamo semplicemente questo messaggio generico all'utente.
‫Quindi, fantastico.
‫Smettiamola qui, torniamo allo sviluppo e
‫concludiamo questa lezione.
‫Allora ci vediamo al prossimo.