JavaScript supporta try/catch/finally ma l’Errore in oggetto si usa funziona in modo diverso da Eccezioni in altre lingue e non fornisce un modo per catturare gli Errori da tipo nello stesso modo che si può con le Eccezioni in Java o C#, quindi è abbastanza comune per tutti gli Errori gettati in un progetto, di istanze di Errore.
Alcuni fornitori hanno implementato una clausola catch condizionale ma non è uno standard e non è ampiamente supportato nei browser.,
Come risultato di non avere un modo standard per definire gli errori — o per restituirli quando li lancia da un server a un client — le informazioni su un errore restituito vengono spesso perse, con progetti con gestione degli errori su misura.
Errori di lancio in altre lingue
Se hai mai usato.NET / Mono potresti apprezzare quanto sia buono il comportamento di gestione degli errori, specialmente per i servizi web.
Se non si ha familiarità con lo stack.NET / Mono nudo con me qui per un minuto, torneremo a come è rilevante di seguito.
Convenzioni di denominazione
.,NET ha convenzioni di denominazione per gli errori, come InputValidationExceptionper gli errori di convalida dell’input eSecurityException per gli errori di autorizzazioni, che è ottimo per incoraggiare la coerenza nella gestione degli errori.
Errori di serializzazione
Un’altra grande caratteristica di.NET è che lanciare automaticamente un’eccezione sul server in un servizio Web può generare automaticamente quell’eccezione in un client che utilizza il servizio, indipendentemente dal fatto che il client sia c#, Java, PHP o JavaScript.,
Questo è possibile grazie al Web Services Description Language (WSDL), che definisce come gli oggetti, comprese le eccezioni, sono serializzati e ha il supporto nativo in alcune lingue (tra cui c# e PHP) e il supporto tramite librerie di terze parti in altri (tra cui Java e JavaScript).
Vantaggi di avere una convenzione
Ciò che è così bello avere convenzioni per gli errori è che rende più facile gestire bene errori specifici perché hanno tipi espliciti e coerenti.,
Con i tipi di errore predefiniti è possibile decidere facilmente quanti dettagli si desidera restituire al client (ad esempio i nomi dei campi che hanno fallito la convalida e cosa c’era di sbagliato in essi) durante la registrazione di ulteriori informazioni di traccia dello stack sul server quando vengono attivati errori imprevisti.
È anche possibile aggiungere proprietà specifiche a un errore, per facilitare l’evidenziazione di un problema, ad esempio un campo di input con un valore non valido.
La serializzazione è automatica e coerente in un’applicazione, anche tra client e server., Ciò rende più facile gestire gli errori lato server e in un’interfaccia utente.
Definizione dei tipi di errore in JavaScript
JavaScript ha in realtà diversi tipi di errore di base per impostazione predefinita, ma sono piuttosto di nicchia e di utilità limitata per la gestione degli errori nella maggior parte delle applicazioni.
Tuttavia, con ES6 è possibile estendere la classe di errore e definire errori personalizzati con il proprio comportamento, come gli errori di registrazione automaticamente, e si può scegliere quali dettagli aggiungere o includere quando si restituisce un errore.,
È possibile definire ogni classe in un file o – se si dispone solo di un piccolo numero di tipi di errore, che è probabilmente il caso per la maggior parte dei progetti – è possibile definirli tutti in un singolo file come esportazioni denominate.
Un esempio di esportazione di diversi tipi di errore come named exports:
È possibile utilizzare errori personalizzati nel codice proprio come si farebbe con un errore normale:
Nota: Questo esempio è per Node.js e usa ‘require’., Se lo stavi scrivendo per ES6 nel browser (o usando Babel per il codice isomorfo) scriveresti l’istruzione include come import { ValidationError } from './error'
Quando lanci un errore personalizzato, puoi controllare che tipo è (ad esempio, osservando il valore di .name) e di decidere come gestire di conseguenza:
la Definizione di un name proprietà, di una proprietà standard della classe di Errore nel JavaScript, fornisce un modo per controllare facilmente il tipo di Errore se è serializzato in un oggetto standard in un periodo di RIPOSO di chiamata o una presa per il servizio di richiamata, quindi si può buttare l’Errore di tutta la strada fino stack—ad esempio da un metodo interno, web server gestore di route, e di un browser —e ancora di sapere cosa è successo.,
Se si restituisce un errore da un servizio basato su REST o socket, l’Errore verrà solitamente serializzato in JSON e viceversa, ed è probabile che venga trasformato in un oggetto semplice (e non più un oggetto Error) nel momento in cui il client valuta la risposta, ma definire tipi di errore come questo nei progetti può ancora aiutare a fornire una convenzione per il ritorno e il controllo degli errori.
Restituendo oggetti Error dalle Promesse
È possibile utilizzare oggetti Error personalizzati anche all’interno di una Promessa.,
È meglio evitare di lanciare errori all’interno di una Promessa, perché potrebbero non essere sempre catturati, a seconda di come è strutturato il codice che li ha chiamati.
Tuttavia è buona norma restituire un errore quando si rifiuta una Promessa e si possono restituire tipi personalizzati di errore proprio come qualsiasi altro errore.
Quando si chiama la funzione, la clausolacatch() può quindi verificare la risposta quando viene restituito un errore. Se restituisci un’istanza di errore (o una classe che la estende) avrai una traccia completa dello stack dell’errore che è stato generato.,
Qualsiasi codice che già utilizza questa funzione e che si aspettava un oggetto Error sarà compatibile con un errore personalizzato che estende la classe Error predefinita.
Serializzazione degli oggetti Error in JSON
Per impostazione predefinita, gli oggetti Error seralizzano in JSON con output come questo:
{ name: 'ValidationError' }
Questo output non è particolarmente utile se si desidera trasferire gli errori direttamente a un front-end web da un framework come Express o Socket.IO.,
È possibile sovrascrivere il metodo di serializzazione per restituire una risposta diversa:
Questo esempio restituisce la risposta incapsulata in una proprietà chiamata ‘error’, rendendo più facile il controllo nelle risposte. Seralizza in JSON in questo modo:
{
error: {
name: 'ValidationError',
message: 'A validation error',
stacktrace: '…'
}
}
Se si dispone di più tipi di errore, è possibile creare la propria classe di errore personalizzata che estende l’errore e quindi basare tutte le classi di errore su quella.,
L’utilizzo dei codici di stato HTTP è appropriato nei servizi HTTP, ma avere un formato standard per gli errori in JSON è ancora utile, specialmente in altri contesti, come le risposte inviate tramite una connessione socket.
Potresti non voler includere una traccia di stack (con nomi di file e numeri di riga) in produzione, ma può essere utile nello sviluppo e nei test e puoi usare un condizionale in modo che vengano restituiti solo in fase di sviluppo.,
Riepilogo
Prendendo spunto da come funziona la gestione degli errori in altri linguaggi come Java e c# e la definizione di errori personalizzati con metodi standard per seralizzarli richiede non richiede molto codice da implementare e fornisce una convenzione coerente e facilmente comprensibile da seguire.
Stabilire buone convenzioni di gestione degli errori in un progetto può rendere più facile migliorare l’esperienza utente del software, squash misteriosi messaggi di “errore sconosciuto”, rintracciare le cause di comportamenti imprevisti e rende più facile registrare, monitorare e segnalare errori.
