Come si assegnano i codici di errore?

Come, quando si sviluppa un progetto di medie dimensioni, si identificano, si creano e si mantengono i codici di errore?

Io per la vita di me non riesco a pensare a un metodo semplice e pulito per farlo. Alcune delle mie idee convertono i nomi di classe e il nome del metodo in una stringa intera, ma questo è troppo lungo da mostrare all'utente in aggiunta al fatto che i nomi dei metodi e i nomi delle classi possono cambiare (speriamo di no!). Altri stanno semplicemente utilizzando un sistema di registro incrementale (ad es. Quando creo un nuovo messaggio di errore, basta aggiungere 1 all'ID dell'ultimo messaggio di errore). Ma questo è completamente non organizzato.

Per essere più specifici, sto parlando di un codice di errore come:

Error 401 Unauthorized.

No.

I codici di errore sono un anacronismo, derivano dai vecchi tempi in cui l'output era davvero difficile e costoso e l'unico modo per segnalare una condizione di errore potrebbe essere stato attraverso un gruppo di spie del pannello frontale:

In questi giorni, abbiamo una gestione matura delle eccezioni integrata in quasi tutti i linguaggi tradizionali. Usalo Fornire all'utente le informazioni con cui può lavorare; non disturbarli con il tecnico blah-blah, ma piuttosto dire loro in modo approssimativo cosa è andato storto e cosa possono fare al riguardo. Per la registrazione, basta dare i nomi descrittivi alle eccezioni e registrare il nome. Più facile da ricordare e anche più facile da trovare utilizzando grep o strumenti di ricerca simili.

L'eccezione è, ovviamente, quando si sta programmando situazioni in cui l'output è ancora difficile e costoso, come sistemi integrati o protocolli di rete. HTTP utilizza ancora codici di risposta numerici perché sono estremamente facili da analizzare in modo efficiente: in alcune situazioni, leggere solo la prima cifra può già dirti abbastanza e puoi scartare il resto del pacchetto.

È necessario verificare come i codici di errore / stato sono organizzati in protocolli comuni come HTTP . Riservano intervalli distinti per diversi tipi di stati / errori. Ciò semplifica sia per gli utenti l'identificazione di un codice di stato sconosciuto, sia per gli sviluppatori di assegnare un codice per un nuovo tipo di errore che non è stato gestito in precedenza.

Siamo spiacenti, perché utilizzare i codici di errore?
Cattura l'eccezione, registralo e offri di inviare un rapporto se il programma non può essere ripristinato .

(Supponendo che la tua lingua supporti le eccezioni.)

Le uniche informazioni rilevanti che potrebbero aiutarti a correggere il bug sono la traccia dello stack che non ottieni con un codice di errore. (Suppongo anche che tu voglia utilizzare i codici di errore per i rapporti di errore e non gettarli in faccia a un utente.)

Assumo un contesto procedurale (C). Se si dispone di oggetti, un oggetto errore è in genere migliore, indipendentemente dall'eccezione.

È necessario utilizzare codici di errore locali per ciascun modulo. Per una libreria puoi avere un'intestazione speciale che elenca i codici di errore, con il numero 1, 2 ecc. (O -1, -2 se preferisci). Assicurati di restituire sempre uno di questi codici, ad esempio traduci errnonei tuoi codici. Se hai più livelli di moduli, traduci ad ogni passo (o predefinisci un intervallo per l'errore più profondo, ad esempio i valori 1001 - 1050 provengono da quell'altro modulo).

È anche importante fornire un mezzo per tradurre il codice in una stringa. Non dovresti mai segnalare solo il codice, il che porta solo alla frustrazione. In realtà praticamente qualsiasi codice nella tua applicazione dovrebbe avere una funzione di traduzione delle stringhe. Ad esempio, libc in genere ha strerrore strsignal, ma purtroppo manca strwaitstatus.