2015-12-08 13 views
7

Sono stato uno sviluppatore .NET per oltre un decennio quindi ecco una domanda vergognosa a cui non ho mai saputo la risposta. Capisco - se un argomento è nullo, posso lanciare un ArgumentNullException. Se cerco di dereferenziare un valore nullo, verrà generata una eccezione NullReferenceException.Quale eccezione devo lanciare per un valore nullo imprevisto?

Ma cosa succede se ho il codice come il seguente:

var someVitalObject = someServiceReference.GetVitalObject(); 

if (someVitalObject == null) 
{ 
    throw new IDontKnowWhatException(); // what exception should I throw here? 
} 

Ora, questo non è necessariamente un problema con il servizio per il quale un'eccezione avrebbe dovuto essere gettato in precedenza.

+0

NullReferenceException? –

+0

È questo un errore nullo nel flusso di esecuzione? Ciò causerà la chiusura della tua app? Forse più contesto ci aiuterà a capire meglio il problema. –

+5

Quindi 'GetVitalObject()' infrange il suo contratto, o è valido per questo restituire null, ma non solo in questo caso? –

risposta

0

Vorrei buttare un System.NullReferenceException. Oppure, se non sei soddisfatto, potresti derivarne da un tipo più specializzato di eccezioni di riferimento null per i tuoi scopi.

+2

No, di solito è il risultato del dereferenziamento di un riferimento null.In pratica sta dimostrando che * non * ha effettuato un controllo sufficiente. Fondamentalmente troverei un'eccezione fuorviante da vedere nei miei registri. –

+2

Lanciare una 'NullReferenceException' sarà molto fuorviante. –

+0

Quindi, quando * do * si lancia un'eccezione di riferimento null? –

4

È difficile dire senza vedere più contesto, ma forse System.InvalidOperationException?

L'eccezione che viene generata quando una chiamata al metodo non è valida per lo stato corrente dell'oggetto.

0

Considerare per creare la propria classe Exception ereditato dal ApplicationException o dalla Exception:

public sealed class MyException : Exception 
{ 
    ... 
} 

questo modo si sarà in grado di controllare il tipo di informazioni per memorizzare in esso.

+0

In generale ereditare da 'ApplicationException' è considerato una cattiva pratica http://stackoverflow.com/questions/52753/should-i-derive-custom-exceptions-from-exception-or-applicationexception-in-net – juharr

+0

@juharr È inutile == cattiva pratica? [ApplicationException considerato inutile] (http://blogs.msdn.com/b/kcwalina/archive/2006/06/23/644822.aspx): * ApplicationException non è considerato dannoso, solo inutile. * – Dmitry

+0

Suppongo che stavo pensando di prendere 'ApplicationException' come una cattiva pratica. – juharr

1

Utilizzare solo System.ArgumentNullException solo quando si verifica direttamente un parametro del metodo, non quando si convalida il risultato di alcune chiamate.

Il tipo di eccezione che lancio dipende molto dal contesto. Ma in questo caso mi sarebbe probabilmente andare a fare un'eccezione personalizzato come:

public class VitalObjectNotAcquiredException : Exception { ... } 
1

Io di solito uso ArgumentNullException per gli oggetti passati in una funzione. Tutto il resto nullo relativo Io uso InvalidOperationException. In casi specifici creerò un'eccezione personalizzata se ha senso.

0

Persino, sceglierei in base al contratto del metodo GetVitalObject. Se questo metodo dovesse restituire un oggetto non nullo, lo cambierei in modo da generare un'eccezione in questo caso.

Se non si ha il controllo sul metodo o se restituire un valore nullo è corretto (ma non nel proprio contesto) andrei con un'eccezione personalizzata come già detto Mark e Dmitry.