‫Jonas: In questo video
‫implementeremo una logica per inviare diversi messaggi di
‫errore per l'ambiente di sviluppo e produzione.
‫Quindi in questo momento stiamo inviando lo stesso messaggio di risposta qui
‫praticamente a tutti, non importa se siamo in fase di
‫sviluppo o di produzione.
‫Ma l'idea è che in produzione vogliamo far trapelare
‫al cliente il minor numero possibile
‫di informazioni sui nostri errori.
‫Quindi, in tal caso, vogliamo solo inviare
‫un messaggio carino e amichevole
‫in modo che l'utente sappia cosa c'è che non va.
‫D'altra parte, durante lo
‫sviluppo scritto, vogliamo ottenere quante più informazioni possibili
‫sull'errore che si è verificato e lo vogliamo
‫proprio nel messaggio di errore che ritorna.
‫Quindi potremmo registrare quelle informazioni anche sulla
‫console, ma penso che sia molto più utile avere
‫quelle informazioni direttamente nel postino, in questo caso.
‫Quindi, sappiamo già come distinguere tra l'ambiente
‫di sviluppo e quello di produzione.
‫E così, facciamolo.
‫Quindi,
‫se il processo. avv. node_env è
‫uguale a development, quindi vogliamo
‫inviare un tipo di
‫errore e se
‫siamo in produzione, vogliamo inviare un errore più semplice.
‫Bene.
‫Quindi uguale alla produzione.
‫Bene, quindi prendiamo questo, quindi di nuovo,
‫quando lo sviluppo
‫scritto, vogliamo ottenere tutte le informazioni che possiamo.
‫Quindi anche qui stampa o rispondi con lo stack di errori.
‫Quindi sbaglia. stack, quindi
‫stampiamo anche l'intero errore.
‫Diciamo errore e impostarlo su OK.
‫Quindi, d'altra
‫parte, ora copiamo questo di nuovo.
‫Quando siamo in produzione, non vogliamo lo stack
‫e non vogliamo nemmeno l'errore completo.
‫Quindi in realtà solo lo stato e il messaggio.
‫Questo qui sembra
‫un po' disordinato, quindi esportiamoli nelle
‫loro funzioni e anche perché aggiungeremo
‫molto più codice qui, in quest'altro ramo.
‫È un po' più pulito avere questi nelle
‫loro funzioni separate.
‫Quindi diciamo
‫const send error for
‫dev e quella funzione dovrebbe quindi
‫ricevere l'errore, e dobbiamo anche passare l'oggetto della risposta.
‫Questo perché è così che possiamo effettivamente
‫inviare la risposta, giusto?
‫Quindi abbiamo bisogno dell'oggetto della risposta per poter eseguire
‫questo codice.
‫Qui chiameremo send error
‫dev con
‫l'errore
‫e la risposta.
‫Quindi quaggiù, invieremo la produzione
‫di errori, gli stessi
‫argomenti.
‫E poi qui, lo stesso.
‫Quindi è stato facile, ora passiamo al livello successivo
‫e parliamo di nuovo degli errori operativi.
‫Per questo, consentitemi di aprire la classe di
‫errore dell'app che abbiamo creato e ricordiamo
‫che contrassegniamo tutti
‫gli errori che creiamo, utilizzando AppError è operativo impostato su true.
‫Quindi tutti gli errori che
‫creiamo noi stessi saranno fondamentalmente errori operativi.
‫In effetti, sono solo questi errori operativi per
‫i quali vogliamo inviare il messaggio di
‫errore al client.
‫Almeno in produzione.
‫Quindi, quando noi, d'altra parte, abbiamo un errore di programmazione,
‫o qualche altro errore sconosciuto che
‫proviene, ad esempio, da un pacchetto di
‫terze parti, non vogliamo inviare alcun messaggio di errore
‫al cliente in produzione.
‫E quindi non serve.
‫Questa è la proprietà operativa qui nel nostro controller di errore.
‫Ricordi come ho già parlato
‫di farlo quando abbiamo creato questa classe, giusto?
‫Veniamo ora qui per inviare la produzione di errori e
‫fare quel test.
‫Se errore. isOperational solo
‫in quel caso vogliamo effettivamente inviare questo errore qui.
‫In tutti
‫gli altri casi, invieremo
‫semplicemente un messaggio di errore molto generico al client.
‫Quindi diciamo, res. status e invieremo
‫semplicemente un codice 500 generico e
‫poi json.
‫Lo stato sarà errore.
‫Allora mandiamo un messaggio generico, dicendo che qualcosa
‫è
‫andato molto storto.
‫Quindi fare qualcosa del genere è una procedura molto standard.
‫Vorrei effettivamente commentare parte del codice qui.
‫Quindi questo è un errore operativo di cui ci fidiamo.
‫Qui vogliamo inviare un messaggio al cliente.
‫Ma in
‫questo caso abbiamo un errore
‫sconosciuto, quindi non vogliamo divulgare i dettagli al cliente.
‫Quindi invieremo questo messaggio al cliente e
‫anche a noi stessi.
‫Per noi sviluppatori, vogliamo sapere
‫che si è verificato questo tipo di errore strano,
‫inaspettato e sconosciuto e lo registreremo effettivamente sulla console.
‫Prima registreremo
‫l'errore, quindi invieremo un messaggio generico.
‫Diciamo solo, consolare. errore, quindi è un po'
‫come console. log, ma
‫è davvero specifico per gli errori e
‫credo che l'output sarà quindi un po' diverso.
‫Quindi errore, aggiungiamo alcune emoji qui per renderlo visibile
‫nei
‫nostri registri, quindi registriamo anche l'errore.
‫Ora ci sono vere librerie di log su mpm, che
‫potremmo usare qui invece
‫di avere solo questa semplice console. errore, ma la
‫semplice registrazione dell'errore sulla console lo
‫renderà visibile nei registri sulla
‫piattaforma di hosting che stai utilizzando.
‫Penso che per ora, in questo tipo di semplice
‫applicazione, basti.
‫Ad esempio, utilizzeremo Heroku entro
‫la fine del corso per distribuire la nostra applicazione.
‫Quindi, quando si verifica un
‫errore come questo, verrà registrato nella console.
‫Nella piattaforma Heroku, abbiamo quindi accesso a questi registri.
‫Possiamo continuare a guardare questi registri e poi lì
‫dentro troveremo questi errori imprevisti in
‫modo da poterli correggere.
‫In questo momento, stiamo già costruendo una sorta
‫di meccanismo di gestione degli errori sofisticato e
‫del mondo reale qui.
‫Quindi ricapitoliamo rapidamente ciò che abbiamo appena fatto qui.
‫Distinguiamo tra errori di sviluppo e di
‫produzione.
‫Quando siamo in produzione, inviamo l'errore usando
‫questa funzione qui,
‫che poi invierà quanti più dettagli possibili al
‫cliente, in
‫modo che otteniamo davvero
‫tutte le informazioni per eliminare il bug.
‫Se si tratta di
‫un errore di programmazione o di
‫un errore operativo, vogliamo comunque vedere cosa sta succedendo.
‫Quando siamo
‫in produzione, che è probabilmente la
‫parte più importante della nostra applicazione, distinguiamo
‫tra errori operativi, quindi
‫errori che conosciamo e di cui
‫ci fidiamo, e altri errori, che potrebbero essere inaspettati.
‫Se l'errore è operativo, quindi ad esempio l'utente ha tentato di
‫accedere a un percorso che non esiste o ha
‫cercato di inserire dati non validi, tutti
‫questi sono errori operativi.
‫Quindi possiamo inviare messaggi di errore appropriati, affinché
‫il cliente sappia cosa è andato storto.
‫D'altra parte, abbiamo questi errori sconosciuti, o
‫errori imprevisti, e in quel
‫caso, diciamo molto semplicemente, qualcosa è andato storto.
‫Quindi registra l'errore anche sulla nostra console, in
‫modo che sappiamo che è successo e possiamo quindi risolverlo.
‫Ora, affinché funzioni, c'è
‫qualcosa di veramente, molto importante che
‫dobbiamo fare.
‫In questo momento ci sono errori
‫che provengono, ad esempio, da MongoDB, che non contrassegniamo come operativi.
‫In questo caso, in questo momento verrebbero semplicemente gestiti utilizzando
‫questo messaggio di errore generico qui.
‫Ad esempio, un errore di convalida.
‫In questo momento, questo è un errore che
‫proviene da MongoDB e non dalla nostra classe di errore dell'app.
‫Non creiamo questi errori da soli.
‫Ancora una volta, al momento non sono contrassegnati come operativi,
‫ma ovviamente dobbiamo contrassegnarli come operativi in modo
‫da poter inviare il messaggio di
‫errore appropriato al client.
‫Nell'esempio che stavo appena menzionando, i dati
‫di input non sono validi.
‫Ci sono altri due o tre errori che dobbiamo contrassegnare
‫come operativi noi stessi.
‫Quindi
‫lo faremo quaggiù.
‫Quindi, in quest'altro
‫blocco, lo faremo nelle prossime due lezioni.