‫-: Quindi, come ho detto
‫nell'ultimo video, ci sono tre tipi di
‫errori che potrebbero essere creati da
‫Mongoose in cui dobbiamo contrassegnare come errori operativi
‫in modo da poter inviare messaggi di errore significativi
‫ai clienti in produzione.
‫E ora iniziamo simulando questi tre errori, ok?
‫Quindi il primo è quando proviamo un ID non valido qui,
‫quindi semplicemente qualcosa del
‫genere, e quindi Mongoose non sarà in grado
‫di convertirlo in un ID MongoDB, ricordalo.
‫E quindi questo è l'errore che otteniamo in questo momento, e
‫in realtà, qui puoi vedere tutto il tipo
‫di cose che abbiamo definito che volevamo vedere nelle produzioni.
‫Quindi l'intero oggetto errore, quindi il messaggio di
‫errore e anche lo stack completo, ok?
‫E quindi questo è un perfetto esempio
‫di errore operativo.
‫Quindi questo è qualcosa che potrebbe benissimo
‫accadere, e quindi dobbiamo inviare una risposta
‫significativa per gestire questo errore.
‫E questo è un perfetto esempio di un errore operativo che
‫è molto probabile che a un certo punto accada a un cliente,
‫quindi dobbiamo gestirlo come tale, va bene?
‫Quindi, fondamentalmente inviando un bel messaggio di
‫errore invece di qualcosa del
‫genere, che non significa nulla per nessun cliente, giusto?
‫Ok, quindi l'obiettivo qui sarà
‫di nuovo sostanzialmente contrassegnare questo errore come operativo
‫e creare un messaggio significativo, ok?
‫Ma prima di poterlo
‫fare, diamo un'occhiata agli altri due
‫errori di Mongoose che dovremo anche contrassegnare come operativi, ok?
‫Quindi, creiamo un nuovo
‫tour e quello che farò è creare un nome duplicato.
‫Quindi, copiamo questo qui.
‫E penso che tutti i
‫valori qui siano corretti, quindi proviamolo ora.
‫E infatti, qui otteniamo l'errore che già conosciamo, che è
‫errore di chiave
‫duplicato perché abbiamo già un
‫tour o un documento con il nome di Forest Hiker, ok?
‫Quindi, di nuovo, questo è un
‫errore che si verificherà ad un certo
‫punto e, di
‫nuovo, non ha un messaggio di errore molto significativo, giusto?
‫E quindi, di nuovo, dobbiamo cambiarlo.
‫Quindi il terzo riguarda anche
‫la convalida, quindi facciamolo qui in Update Tour.
‫Quindi, diciamo che vogliamo avere una media di rating di
‫sei, che sappiamo non essere valida, giusto?
‫Perché abbiamo detto che il massimo delle valutazioniAverage
‫potrebbe essere cinque.
‫Quindi vediamo,
‫e in effetti, otteniamo questo ValidationError, giusto?
‫Quindi si chiama ValidationError
‫e ha questo oggetto errors con tutti gli errori.
‫In realtà ne mettiamo un altro qui.
‫Quindi diciamo difficoltà,
‫e poi qualcos'altro, quindi
‫uno che non sia facile, medio o
‫difficile, e quindi ora otteniamo questi due oggetti qui.
‫Quelli per le valutazioni e uno per la difficoltà, va bene?
‫Quindi questi sono
‫i tre errori che
‫contrassegneremo come operativi, a partire da
‫questo primo, quindi fondamentalmente, il tipo CastError, ok?
‫Quindi, torniamo qui, e lo faremo
‫di nuovo qui, perché vogliamo farlo solo in produzione, ok?
‫In fase di sviluppo, non ci interessa niente di tutto questo.
‫Tutto ciò che vogliamo fare è
‫vedere i nostri errori in modo che possiamo
‫sostanzialmente risolverli, ma in produzione, è qui
‫che vogliamo inviare i messaggi di errore significativi ai client.
‫Quindi, diciamo se sbagli. name è uguale
‫a CastError, quindi è così che identificheremo questo tipo
‫di errore di cui
‫abbiamo appena parlato, perché
‫ha il nome di CastError, va bene?
‫Quindi se sbagli. name
‫è CastError, allora chiameremo una funzione speciale che creeremo
‫in un secondo,
‫che si chiama handleCastError.
‫E poi dirò anche qui DB per database,
‫così sappiamo che questo è correlato al nostro database, ok?
‫Ed è così che funzionerà.
‫Passeremo l'errore creato
‫da Mongoose in questa funzione,
‫quindi proprio come questo, e questo
‫restituirà un nuovo errore creato senza la classe AppError, ok?
‫E quell'errore verrà quindi contrassegnato come operativo, perché
‫ricorda, tutti i nostri AppError
‫hanno le proprietà
‫operative impostate su due automaticamente, giusto?
‫Quindi questo restituirà un errore, quindi salviamolo, ok?
‫E così lo stavano salvando in errore.
‫Ora non è affatto
‫una buona pratica sovrascrivere gli argomenti di una funzione, ok?
‫Quindi l'errore deriva da questa funzione di errore centrale, giusto?
‫Quindi, da qui, e quindi invece
‫di farlo, creerò effettivamente
‫una copia cartacea di quell'oggetto errore, ok?
‫Quindi let, e sto usando let e non const,
‫perché ovviamente riassegniamo un
‫nuovo errore in seguito, più avanti qui.
‫Quindi, chiamiamo questo errore invece di solo err,
‫che è il nome normale degli errori in Express.
‫E così ancora, useremo il
‫nostro trucco per cui usiamo la destrutturazione dell'errore originale, ok?
‫E così, d'ora in poi, useremo questo errore invece di err.
‫Quindi qui, e qui, e qui.
‫Bene?
‫E quindi, ora andiamo avanti
‫e creiamo effettivamente questa funzione qui.
‫Quindi mettiamolo qui proprio all'inizio.
‫Bene.
‫Cerca di ricordare che questo riceve un
‫errore, e ora tornerò a chiamarlo semplicemente err in questo modo,
‫perché di nuovo è una specie di standard in Express.
‫E per iniziare,
‫diamo un'occhiata di nuovo all'oggetto errore qui, ok?
‫Quindi qui abbiamo il percorso e abbiamo anche il valore, ok?
‫Quindi il percorso qui è fondamentalmente il nome del
‫campo per il quale i dati di input sono nel formato sbagliato, ok?
‫E quel valore qui è poi questo, che
‫è, ovviamente, quello che abbiamo fatto in passato, va bene?
‫Quindi, questo potrebbe accadere non solo per l'ID, ma in
‫realtà per qualsiasi campo che interroghiamo
‫con un valore nel formato sbagliato, va bene?
‫E quindi, ora creiamo fondamentalmente
‫una stringa che dice che abbiamo
‫un ID non valido con il valore di questo in questo caso, va bene?
‫Quindi, è percorso e valore, ok?
‫Quindi, creiamo un messaggio qui e diciamo
‫Invalid err. il percorso è
‫errato. valore.
‫Bene?
‫E così ora, restituiamo semplicemente il nostro AppError.
‫Bene?
‫Quindi, proprio come ho già detto un paio di volte, ok?
‫Quindi AppError, e in realtà devo includerlo qui,
‫o richiederlo, perché non l'ho ancora fatto.
‫Quindi const AppError è uguale a require e si sposta
‫di un livello verso l'alto, quindi nella cartella delle
‫utilità e quindi in appError.
‫Ecco qui.
‫E così ora, in o AppError, passiamo il nostro messaggio e
‫il codice di stato 400, che sta per Bad Request.
‫Ok, e così, proprio così, trasformiamo
‫lo strano errore che stavamo
‫ricevendo da Mongoose in un
‫errore operativo con un
‫simpatico messaggio amichevole che (ridacchia) un
‫vero
‫essere umano può leggere, va bene?
‫Ok, un'ultima cosa che dobbiamo
‫cambiare qui è impostare anche questo qui su errore, ok?
‫E quindi, in questo momento, se il nostro errore
‫è CastError, bene, passeremo l'errore a questa funzione
‫che restituirà il nostro AppError, quindi questo,
‫e questo è quello che verrà quindi inviato al
‫client utilizzando il nostro sendErrorProd, bene?
‫E quindi, ora proviamoci davvero.
‫Quindi qui, nel nostro pacchetto. json,
‫abbiamo questo script start:prod, quindi proviamolo.
‫Quindi, npm run start: prod, e posso effettivamente completare automaticamente questi nomi
‫di script npm usando la scheda qui nel terminale, ok?
‫E quindi, questo avvierà
‫un processo in modalità di produzione, fondamentalmente, ok?
‫E quindi, ora proviamo di nuovo.
‫Quindi, se stai facendo questa
‫richiesta, dovremmo ricevere il messaggio di
‫errore che abbiamo appena creato, perché in questo momento siamo in produzione.
‫E infatti, eccolo qui.
‫Quindi abbiamo non valido, quindi il nome del campo, o
‫in realtà il nome del percorso, e quindi il valore
‫che abbiamo inserito.
‫Quindi, se proviamo qualcosa
‫di diverso, ovviamente otteniamo questo
‫e, naturalmente, anche il nostro codice 400 Bad Request.
‫Ok, fantastico.
‫Quindi, questo è ora gestito.
‫Nella prossima lezione, ci occuperemo poi della prossima, che è
‫per i nomi di campo duplicati, va bene?
‫Allora, ci vediamo tra un secondo.