Gestione degli errori personalizzata

Ho trascorso molto tempo a considerare questo problema. Credo che il problema più importante nella scrittura dei messaggi di errore sia comunicare con precisione all'utente. Lo scopo di un messaggio di errore per aiutare l'utente ad eliminare il problema che esisteva. Un tale problema potrebbe essere un fraintendimento tra l'utente e il programma (cioè l'utente pensava che un nome di file potesse avere una barra nel nome, ma semplicemente non è possibile) o potrebbe essere un problema ambientale (cioè il disco si esauriva di spazio).

Nella mia esperienza, la maggior parte dei software presenta una segnalazione di errori scadente. O numeri criptici o messaggi di errore generici sovrautilizzati senza specifiche. Devi fare tutto ciò che serve per comunicare nel modo più accurato e completo possibile. Tutto ciò che ostacola questo ridurrà la qualità dei messaggi di errore. La domanda da porsi è: come farò tutti i messaggi di errore nel miglior modo possibile.

Ho trovato, quindi, che inserire il messaggio di errore completo direttamente nel codice è il modo migliore per assicurarsi che il messaggio sia chiaro, accurato e completo. Lavoro su alcuni codici di grandi dimensioni (> 1 milione di righe di codice) e NON ho avuto problemi a trovare questi messaggi di errore cercando, perché ho reso il messaggio di errore il più completo possibile.

Se ho lo stesso errore riportato molte volte, creo un metodo / subroutine e inserisco il test e l'eccezione, invece di copiare lo stesso codice in molti punti.

Non ho nulla contro la definizione di un insieme di costanti e quindi li uso per cercare il messaggio di errore, ma

• Ho scoperto che la maggior parte dei programmatori genererà messaggi molto più poveri in questo caso.
• Il sovraccarico extra di allocare una nuova costante e mettere quel testo in un altro file di risorse, e quindi organizzare una chiamata, è un sovraccarico sufficiente che i programmatori spesso riutilizzano semplicemente un messaggio esistente anche quando non è un perfetta vestibilità .
• I programmatori pensano che torneranno più tardi e ne forniranno uno migliore, ma non lo fanno mai.
• Una volta rimosso dal contesto del codice che sta verificando il problema, è difficile scrivere un messaggio di errore preciso.
• La diffusione di queste informazioni su due o tre file diversi rende il codice più complicato e difficile da mantenere.
• Una volta definita una costante, è difficile rimuoverla anche se rimuovi il codice originale
• Se la condizione cambia, è difficile sapere se è possibile modificare il messaggio o se deve essere creato un nuovo messaggio.
• Se il tuo obiettivo è in modo chiaro, accurato e completo comunicare all'utente , quindi l'utilizzo di costanti e file di ricerca interferisce con di tali comunicazioni, senza alcun reale beneficio compensativo.

In realtà, separo gli errori in due categorie: errori che possono essere dovuti all'input dell'utente e errori a causa dei programmatori . Quelli per gli utenti devono essere localizzabili e quelli devono fare riferimento a file di risorse. Per questi, utilizzo costanti che NON sono numeriche, ma sono piuttosto approssimazioni del messaggio di errore. Quindi il pacchetto di risorse usa quello per cercare una versione localizzata del messaggio. Tuttavia, per gli errori del programmatore, li incorporo direttamente nel codice e ottieni solo l'inglese. Trovo che la maggior parte (forse dal 60% al 75%) sono errori orientati al programmatore.

Forse la soluzione più semplice potrebbe essere quella di definire un insieme di variabili costanti che facciano riferimento al messaggio di errore. Questo dovrebbe darti il meglio di entrambi i mondi, dal momento che puoi modificare facilmente il messaggio di errore modificando la costante, e la costante può essere nominata per darti un'idea di cosa sia l'errore quando stai leggendo il codice.

Supponendo che si tratti di PHP, utilizzerei il codice come il seguente in un file che includi ovunque:

define("ERR_FOO", "Error foo occurred.");
define("ERR_BAR", "Error bar occurred.");

Quindi nel tuo codice:

if(expr) {
} else {
    $_SESSION['error'] = ERR_BAR;
}

EDIT : tendo ad essere d'accordo sul fatto che i messaggi di errore destinati esclusivamente al consumo umano dovrebbero essere scritti nel codice come stringhe letterali nel punto in cui vengono utilizzati. Sebbene possa essere probabilmente dedotto dal contesto, la domanda non specificava se gli errori sarebbero stati letti dagli umani una volta memorizzati in $ _SESSION ['errore'] o se qualche codice successivo avrebbe dovuto controllare $ _SESSION ['errore'] e agire in base al suo valore. Sarebbe difficile realizzare quest'ultimo caso d'uso con stringhe codificate solo.