Come dovrebbero essere indicati i livelli di errore?

Non aggiungere livelli non necessari ai tuoi codici di errore. Potresti passare secoli inutilmente a discutere se un dato errore debba essere un livello 83 o solo un livello 82. Tutto ciò che interessa l'utente finale è se il sistema funziona correttamente o se è rotto.

Quindi userei qualcosa come INFO (non un errore), WARNING (il sistema sta funzionando bene, ma potrebbe non fare quello che ti aspettavi), ERRORE (qualcosa è andato storto, ma il sistema è stato ripristinato) e FATAL (il sistema è rotto e non funziona più). Potresti forse dividere ERROR in MAJOR e MINOR, a seconda di come l'errore ha influito sull'output.

Se i codici di errore aumentano o diminuiscono con severità è del tutto arbitrario. Assicurati che sia ben documentato.

La domanda di design è: Cosa faranno le persone con i numeri di livello?

Per lo più: filtraggio dei messaggi del registro. Per questo, sono sufficienti cinque livelli. Vedi per es. Livelli di registrazione di Android . (Se hai bisogno di filtri più selettivi, sarà molto più efficace filtrare su altri criteri come il modulo sorgente.)

Scegli una regola per decidere quale livello utilizzare quando, e se non scegli una regola semplice, passerai molto più tempo a decidere quale livello utilizzare ogni volta rispetto al valore che otterrai da questo.

I livelli di Android sono basati sulla severità (impatto), che rende abbastanza facile decidere quale livello utilizzare.

Non visualizzare i numeri del livello di errore per gli utenti del software a meno che non fornisca loro un'utilità chiara come l'abilitazione di uno strumento di compilazione per decidere se procedere. In caso contrario, un test di usabilità mostrerebbe probabilmente che gli utenti sono infastiditi dal dover leggere oltre quei numeri.

I livelli di errore sono usati per il debug, cioè per determinare cosa va inserito nel log. Scegli una direzione per il livello di importanza e bastone con esso.

Spesso è meglio se puoi modificare il livello di errore che il log sta segnalando in fase di esecuzione.

>

typedef enum  
{  
    E_LOG_NONE=0,  /// never log - unit test only  
    E_LOG_ERROR,   /// highest priority - always report this error  
    E_LOG_WARN,    /// Show warnings + errors. Not an error, but a strange situation  
    E_LOG_INFO,    /// Anything appropriate for production logging  
    E_LOG_VERBOSE, /// Development info - function calls or message receipts  
    E_LOG_DEBUG,   /// super noisy - print hex output, etc  
} LOG_VERBOSITY_LEVELS;  

Quindi normalmente il log riporta solo al livello "X", ma se lo desideri puoi aumentare la verbosità. Nota idealmente avrai la possibilità di impostare diverse sezioni del codice a diversi livelli di dettaglio dell'errore.

Puoi anche fornire numeri specifici di errore, ad esempio "numero di errore" ai fini del data mining del log, ovvero "grep [stringa numero errore] [file log] | wc" riporterà quante istanze del numero di errore X si sono verificate , ovviamente questo può essere automatizzato.