Gestione degli errori in modo coerente

Gli errori possono assumere la forma di un'eccezione generata, un oggetto Error appropriato, un oggetto semplice, un argomento facoltativo a un callback, un Promise, un valore di ritorno speciale, una stringa semplice, ecc. A un certo punto, tutti questi devono essere convertiti in alcuni messaggi per l'utente. Come si converte tra tutte le varie forme, dove avviene questa conversione, dove dovrebbe essere gestita / inoltrata all'interfaccia utente e che dovrebbe essere / contenere un errore?

Da un punto di vista pratico, penso che abbia senso fare la conversione in un posto, forse appena prima che l'errore venga inviato all'utente. Nel caso di applicazioni web, questo sarebbe il middleware chiamato dopo che una risposta è stata generata, ma prima che venga inviata al browser. Questo middleware potrebbe normalizzare la risposta in modo che segua una forma comune (come un oggetto JSON con title , description , original-error e backtrace proprietà - vedere "Comunicazione efficace degli errori agli utenti e agli sviluppatori" di seguito), e registra le informazioni rilevanti ai fini del debug.

Inoltre, a volte si verificano più errori simultanei (come errori di convalida), quindi errori oggetti / risposte / ecc. dovrebbe rappresentare un elenco di errori - nella maggior parte dei casi, ci sarà probabilmente un singolo elemento in questo elenco.

Per complicare le cose, a volte il codice UI ha errori e questo deve essere registrato per scopi di debug. Ancora una volta, nel caso dell'applicazione web, il webserver potrebbe includere una route HTTP che accetta dati di errore dal browser e registra queste informazioni nella stessa posizione degli errori generati dal server.

Comunicare in modo efficace l'errore agli utenti e agli sviluppatori

È probabilmente utile distinguere tra un errore messaggio per sviluppatori / supporto e un messaggio di errore per gli utenti, ma la causa principale è ancora un singolo errore. Quindi questo singolo errore dovrebbe contenere abbastanza informazioni per sviluppatori / supporto per identificare rapidamente il problema, ma anche abbastanza informazioni in modo che un messaggio possa essere mostrato agli utenti che ha senso - si spera con passaggi per risolvere il problema / risolvere il problema.

Detto questo, sembra che un buon errore conterrebbe una descrizione tecnica per gli sviluppatori (con backtrace se possibile), un breve messaggio per gli utenti e una descrizione dettagliata del problema (con soluzioni alternative, se possibile). La sicurezza deve essere considerata (i backtrace possono rivelare i meccanismi interni del tuo programma).

Poiché JSON è un formato agnostico di lingua / protocollo, ecco come può apparire un errore da un'API REST:

{
   "errors": [{
      "title": "User already exists",
      "description": "Somebody's already using that username - please try a different username",
      "original-error": {
         "message": "DatabaseError entity exists",
         "backtrace": "... use your imagination ..."
      }
   }, {
      "title": "Cannot use temporary email accounts",
      "description": "Email addresses with the disposable email provider, mailinator.com, cannot be used. Please use a different address."
      "original-error": "DocumentValidationError mailinator.com is not supported"
   }]
}