Cosa registrare quando si verifica un'eccezione?

Question

public void EatDinner(string appetizer, string mainCourse, string dessert) 
{ 
    try 
    { 
     // Code 
    } 
    catch (Exception ex) 
    { 
     Logger.Log("Error in EatDinner", ex); 
     return; 
    } 
} 

Quando si verifica un'eccezione in un metodo specifico, cosa devo registrare?

Vedo molto di quanto sopra nel codice con cui lavoro. In questi casi, devo sempre parlare con la persona che ha riscontrato l'errore per scoprire che cosa stavano facendo, scorrere il codice e provare a riprodurre l'errore.

Esistono buone pratiche o modi per minimizzare tutto questo lavoro extra? Devo registrare i parametri in ogni metodo come questo?

Logger.Log("Params: " + appetizer + "," + mainCourse + "," + dessert, ex); 

C'è un modo migliore per registrare l'ambiente corrente? Se lo faccio in questo modo, dovrò scrivere tutte queste cose per ogni metodo che ho nella mia applicazione? Esistono buone pratiche in merito a scenari come questo?

Answer 1

Come regola generale, direi sforzarsi di registrare tutte le informazioni necessarie per riprodurre il corso degli eventi che portano a un errore. Si noti che non è necessario registrare tutto all'interno del blocco catch: è possibile inserire istruzioni di debug nel codice, all'interno dei metodi chiamati ecc. Che consentono di seguire ciò che stava accadendo direttamente prima dell'eccezione. Inoltre, dovresti inserire le informazioni nell'eccezione stessa sul sintomo esatto che lo ha causato.

IMHO che passa attraverso tutto il codice per aggiungere istruzioni di registro ovunque può essere eccessivo - o almeno, non redditizio in un progetto di vita reale. Invece, concentrati sulle parti di codice più importanti per massimizzare i ritorni dai tuoi sforzi. Queste parti di codice sono in genere in cui si verificano la maggior parte dei bug e/o la maggior parte delle modifiche vengono eseguite. Quindi, in pratica ogni volta che devi toccare un pezzo di codice, pensa al logging, controlla le istruzioni del registro già presenti (se ce ne sono), controlla la gestione delle eccezioni (se ce n'è una - io di routine vedo non solo il codice come il tuo esempio che semplicemente inghiotte l'eccezione catturata, ma anche blocchi vuoti o autogenerati catch nel nostro codice legacy ... tutti questi possono lasciare l'applicazione in uno stato indefinito, che è una COSA MALE), e pensare se ciò che è già lì è sufficiente per te per riprodurre errori e capire cosa è successo se si verifica un errore. Quindi miglioralo il più possibile e con un ragionevole sforzo.

aiuta anche per discutere di questo argomento con i tuoi compagni di squadra e cercare di elaborare una convenzione del progetto di massima di come registrare gli eventi, come gestire le eccezioni, ecc Questo potrebbe risparmiare un sacco di tempo altrimenti speso per i bug a caccia e/o migliorare il codice prodotto dai tuoi stessi colleghi :-(

Answer 2

Questo è un codice piuttosto orribile. Mangia l'eccezione, presumibilmente lasciando l'applicazione in uno stato indefinito. In generale, con tutti i mezzi, registra l'eccezione (ma don ') t avvolgere ogni bit di codice in un blocco try), ma poi rilanciarlo

Answer 3

Il tuo framework di registrazione dovrebbe catturare il più possibile il contesto per te. per lo meno può facilmente catturare la classe in cui si è verificato l'errore. Dovrebbe anche registrare l'eccezione completa incluso lo stacktrace e le eventuali eccezioni interne.

As I answered in your other question è necessario utilizzare diversi livelli di registro. Una volta fatto questo, se si sta utilizzando un'inversione del contenitore di controllo, è un compito abbastanza semplice cablare un intercettore che intercetterà tutte le chiamate di metodo e se si è in modalità debug loggare la chiamata, il timestamp e tutti i parametri.

Answer 4

Questo è un example di Rico Mariani (CLR perf) perché non si devono prendere tutte le eccezioni.Può essere davvero difficile diagnosticare il vero problema.