Un modo migliore per gestire NullReferenceExceptions in C#

Question

Recentemente ho avuto un bug di codifica in cui, in determinate condizioni, non veniva inizializzata una variabile e ricevevo un NullReferenceException. Ciò ha richiesto un po 'di tempo per eseguire il debug poiché dovevo trovare i bit di dati che generano questo per ricreare l'errore in quanto l'eccezione non fornisce il nome della variabile.

Ovviamente potrei controllare ogni variabile prima dell'uso e lanciare un'eccezione informativa ma c'è un modo migliore (leggi meno codice) per farlo? Un altro pensiero che avevo era la spedizione con i file pdb in modo che le informazioni di errore conterrebbero la riga di codice che ha causato l'errore. Come fanno gli altri a evitare/gestire questo problema?

Grazie

Answer 1

In primo luogo: non fare troppo in una singola istruzione. Se hai un numero enorme di operazioni di dereferenziamento in una riga, sarà molto più difficile trovare il colpevole. Il Law of Demeter aiuta anche con questo - se hai qualcosa come order.SalesClerk.Manager.Address.Street.Length allora hai un sacco di opzioni da guadare quando ottieni un'eccezione. (Sono non dogmatica circa la Legge di Demetra, ma tutto con moderazione ...)

In secondo luogo: preferisco fusione rispetto all'uso di as, a meno che sia valida per l'oggetto sia un tipo diverso, che normalmente comporta un controllo nulla immediatamente dopo. Così qui:

// What if foo is actually a Control, but we expect it to be String? 
string text = foo as string; 
// Several lines later 
int length = text.Length; // Bang! 

Qui ci saremmo un NullReferenceException e, infine, risalire al text essere nulla - ma poi non si sa se è perché foo era nullo, o perché era un tipo di inaspettato. Se dovesse davvero, davvero essere un string, poi gettato invece:

string text = (string) foo; 

Ora sarete in grado di capire la differenza tra i due scenari.

In terzo luogo: come altri hanno già detto, convalidare i dati, in genere argomenti per API pubbliche e potenzialmente interne. Lo faccio in un numero sufficiente di posti in Noda Time che ho una classe di utilità per aiutarmi a decodificare il controllo. Così, per esempio (da Period):

internal LocalInstant AddTo(LocalInstant localInstant, 
          CalendarSystem calendar, int scalar) 
{ 
    Preconditions.CheckNotNull(calendar, "calendar"); 
    ... 
} 

Si dovrebbe documento ciò che può e non può essere nullo, anche.

Answer 2

Mi dispiace dire che eseguirò sempre un controllo per verificare che qualsiasi oggetto che sto usando in un particolare metodo non sia nullo.

E 'semplice come

if(this.SubObject == null) 
{ 
    throw new Exception("Could not perform METHOD - SubObject is null."); 
} 
else 
{ 
... 
} 

Altrimenti non riesco a pensare a un modo di essere approfondita. Non avrebbe molto senso per me non fare questi controlli comunque; Sento che è solo una buona pratica.

Answer 3

Prima di tutto è necessario sempre convalidare i dati immessi. Se null non è consentito, lanciare un ArgumentNullException.

Ora, so come può essere doloroso, in modo da poter esaminare gli strumenti di riscrittura degli assemblaggi che lo fanno per te.L'idea è che si avrebbe una sorta di attributo che avrebbe segnato questi argomenti che non possono essere null:

public void Method([NotNull] string name) { ... 

E il masterizzatore sarebbe riempire gli spazi vuoti ...

O una semplice estensione metodo potrebbe rendere più facile

name.CheckNotNull(); 

Answer 4

in molti casi è quasi impossibile da pianificare e conto per ogni tipo di eccezione che potrebbe accadere in qualsiasi punto del flusso di esecuzione dell'applicazione. La codifica difensiva è efficace solo fino a un certo punto. Il trucco consiste nell'avere un solido stack di diagnostica incorporato nell'applicazione in grado di fornire informazioni significative sugli errori non gestiti e sugli arresti anomali. Avere un buon gestore di primo livello (ultimo fosso) a livello di dominio app ti aiuterà molto.

Sì, la spedizione dei PDB (anche con una versione di rilascio) è un buon modo per ottenere una traccia di stack completa in grado di individuare la posizione esatta e le cause degli errori. Ma qualunque sia l'approccio diagnostico che scegli, deve essere inserito nel progetto dell'applicazione per cominciare (idealmente). L'aggiornamento di un'app esistente può essere noioso e richiede tempo e denaro.

Answer 5

Se siete solo in cerca di un modo più compatto al codice contro avere riferimenti nulli, non trascurare l'operatore null coalescenza ??MSDN

Ovviamente, dipende da cosa si sta facendo, ma può essere usato per evitare dichiarazioni extra se