marcatori di errore interni

Question

Teoricamente, l'utente finale non dovrebbe mai vedere errori interni. Ma in pratica, teoria e pratica differiscono. Quindi la domanda è cosa mostrare all'utente finale. Ora, per l'utente totalmente non tecnico, vuoi mostrare il meno possibile (" fai clic qui per inviare una segnalazione di bug " tipo di cose), ma per gli utenti più esperti, lo faranno vuoi sapere se c'è un lavoro in giro, se è noto da un po 'di tempo, ecc. Quindi vuoi includere alcune informazioni su ciò che è sbagliato.

Il modo classico per farlo è o un'asserzione con un nome file: numero-riga o una traccia dello stack con lo stesso. Ora questo è positivo per lo sviluppatore perché lo indica proprio il problema; tuttavia ha alcuni aspetti negativi significativi per l'utente, in particolare che è molto criptico (ad esempio ostile) e le modifiche al codice cambiano il messaggio di errore (Google cerca l'errore funziona solo per questa versione).

Ho un programma che sto programmando di scrivere dove voglio affrontare questi problemi. Quello che voglio è un modo per associare un'identità unica a ogni asserzione in modo tale che la modifica del codice attorno all'asserzione non la alteri. (Ad esempio, se lo taglio / incollo in un altro file, voglio che vengano visualizzate le stesse informazioni) Qualche idea?

Una virata a cui sto pensando è quella di avere un elenco per gli errori, ma come assicurarsi che non vengano mai utilizzati in più di un posto?

(Nota: per questa domanda, Sto osserviamo solo gli errori causati da errori di codifica. Non cose che potrebbero legittimamente verificarsi come input errato. OTOH questi errori potrebbero essere di qualche interesse per la comunità in generale.)

(Nota 2: il programma in questione sarebbe un'app della riga di comando in esecuzione sul sistema dell'utente. Ma ancora una volta, questa è solo la mia situazione.)

(Nota 3: la lingua di destinazione è D e Sono molto disposto ad immergermi in meta-programmazione . Risposte per altre lingue più che benvenute!)

(nota 4: voglio esplicitamente NON usare posizioni di codice effettive ma piuttosto una sorta di nomi simbolici per gli errori. Questo perché se il codice viene modificato praticamente in qualsiasi modo, le posizioni di codice cambiano.)

Answer 1

Scrivi uno script per eseguire grep sull'intero albero dei sorgenti per l'utilizzo di questi codici di errore, quindi lamentati se ci sono duplicati. Esegui quello script come parte dei tuoi test unitari.

Answer 2

Domanda interessante. Una soluzione che ho usato più volte è questa: se si tratta di un errore fatale (ad esempio errori non fatali dovrebbe dare all'utente la possibilità di correggere l'input), generiamo un file con molte informazioni pertinenti: le variabili di richiesta, intestazioni, informazioni sulla configurazione interna e backtrace completo per il debug successivo. Lo memorizziamo in un file con un nome file univoco generato (e con l'ora come prefisso).

Per l'utente, presentiamo una pagina che spiega che si è verificato un errore irreversibile e chiediamo che includano il nome file come riferimento se desiderano segnalare il bug. Molto più facile eseguire il debug con tutte queste informazioni dal contesto della richiesta offensiva.

In PHP la funzione debug_backtrace () è molto utile per questo. Sono sicuro che esiste un equivalente per la tua piattaforma.

Ricorda inoltre di inviare le intestazioni http pertinenti: probabilmente: Errore interno server HTTP / 1.1 500

Dato un formato ragionevole del file di segnalazione errori, è anche possibile analizzare gli errori che gli utenti non hanno segnalato.

Answer 3

Non so nulla della tua lingua di destinazione, ma questa è una domanda interessante a cui ho pensato e volevo aggiungere i miei due centesimi.

La mia sensazione è sempre stata che i messaggi per errori gravi ed errori interni dovessero essere il più utili possibile affinché lo sviluppatore identificasse il problema & amp; risolvilo rapidamente. La maggior parte degli utenti non guarderà nemmeno questo messaggio di errore, ma gli utenti finali altamente sofisticati (forse quelli del supporto tecnico) avranno spesso una buona idea di quale sia il problema e persino escogitare nuove soluzioni alternative guardando messaggi di errore altamente dettagliati. La chiave è rendere dettagliati quei messaggi di errore senza essere criptici, e questa è più un'arte che una scienza.

Un esempio di un programma Windows che utilizza un server COM out-of-proc. Se il programma principale tenta di creare un'istanza di un oggetto dal server COM e non riesce con il messaggio di errore:

  

" ATTENZIONE: impossibile creare un'istanza   UtilityObject: errore "Classe non   Registrato "in" CoCreateInstance ""

Il 99% degli utenti lo vedrà e penserà che sia scritto in greco. Una persona dell'assistenza tecnica può rendersi conto rapidamente che ha bisogno di ri-registrare il server COM. E lo sviluppatore saprà esattamente cosa è andato storto.

Per associare alcune informazioni contestuali all'asserzione, nel mio codice C ++ userò spesso una semplice stringa con il nome del metodo, o qualcos'altro che chiarisca dove si è verificato l'errore (chiedo scusa per aver risposto in un lingua di cui non hai chiesto):

int someFunction()
{
  static const std::string loc = "someFunction";
  :  :
  if( somethingWentWrong )
  {
    WarningMessage(loc.c_str(), "Unable to Instantiate UtilityObject:  Error 'Class Not
    Registered' in 'CoCreateInstance);
  }
}

... che genera:

  

AVVERTENZA [someFunction]: impossibile   Instantiate UtilityObject: errore   "Classe non registrata" in   'CoCreateInstance