Che tipo di eccezione per gettare

Question

Che typeo d'eccezione lanceresti da una proprietà di sola lettura quando l'oggetto che viene utilizzato per il valore di ritorno è nullo

public class TestClass 
{ 
    SomeObject obj; 
    public string NameOfObject 
    { 
     get 
     { 
      if(obj == null) 
      { // what exception type to throw here } 
      return obj.Name; 
     } 
} 

Answer 1

Un InvalidOperationException è quello che vorrei utilizzare in questo caso, perché l'accesso alla proprietà non è valido per lo stato corrente dell'oggetto.

Secondo la documentazione MSDN:
"L'eccezione che viene generata quando una chiamata al metodo non è valida per lo stato corrente dell'oggetto."
anche:
"InvalidOperationException viene utilizzato nei casi in cui l'errore di richiamare un metodo è causato da motivi diversi da argomenti non validi."

In questo caso obj non è un argomento, che è il motivo per cui avrei magra verso "InvalidOperationException"

Il motivo per cui non vorrei gettare un NullReferenceException qui: se non ha ancora aggiungere qualsiasi codice speciale, questo è il eccezione che ".Net" avrebbe gettato, quindi perché aggiungere codice ridondante?

Answer 2

A meno che non si sta dicendo da qualche parte che questa proprietà non sarà mai essere nullo, perché dovresti lanciare un'eccezione?

Detto questo, se hai garantito che, vorrei buttare un InvalidOperationException.

InvalidOperationException è

L'eccezione generata quando una chiamata metodo è valido per lo stato corrente dell'oggetto .

Answer 3

Vorrei buttare un InvalidOperationException.

ArgumentNullException lancio solo se i parametri dei metodi sono nulli.

Se il parametro metodi è in uno stato non valido, viene generato un valore ArgumentException.

Answer 4

Non si dovrebbe lanciare NullReferenceException. È riservato alle situazioni in cui un oggetto nullo è dereferenziato. In questo caso, se dovessi lanciare NullReference, potresti anche lasciare il check null e lasciare che sia il framework a lanciarlo quando tenti di accedere al Nome dell'obj.

Vorrei buttare invece InvalidOperationException.

Answer 5

mi piacerebbe gettare un InvalidOperationException, ma solo se: - E 'legale per obj di essere null, ed è responsabilità dell'utente per verificare la presenza di questo, o - non è legale per obj di essere null in primo luogo (cioè, obj != null è una classe invariante)

Se nessuno di quanto sopra è il caso (cioè, è legale per obj di essere null, e codice utente non è espressamente richiesta per verificare questa prima dell'uso la proprietà), quindi non mi butto affatto ma piuttosto restituisco null.

Answer 6

Vorrei rivisitare il progetto in modo che questo stato non possa esistere in primo luogo, cioè obj è nullo. Generalmente da una prospettiva API dovresti essere in grado di chiamare un getter in buona fede che non esploderà a causa del fatto che l'oggetto si trova in uno stato sconosciuto.

Ad esempio, perché non utilizzare 'SomeObject obj' come parametro del costruttore e utilizzare la convalida dell'argomento nel punto di costruzione. Ciò assicurerà che lo stato di 'obj' sia sempre corretto, cioè non nulla dopo la costruzione.

Esistono molti modelli che possono essere utilizzati per garantire che un oggetto abbia uno stato corretto quando diventa disponibile per l'utente.

Answer 7

Ognuno ha coperto l'ovvio, quindi ecco un'altra opzione.

Se la classe deve essere inizializzata in qualche modo (il proprio SomeObject deve essere impostato ad un certo punto), considerare l'implementazione di ISupportInitialize. Ciò indica agli utenti della tua classe che non è in uno stato valido prima della chiamata allo EndInit(). Sfortunatamente, non esiste un generale preesistente NotInitializedException che è possibile utilizzare (ce ne sono alcuni ma sono specifici per determinati spazi dei nomi), quindi suggerirei di associare l'implementazione dell'interfaccia con la creazione di tale eccezione.

Gli utenti devono prima chiamare il numero BeginInit(), quindi configurare l'istanza, quindi chiamare EndInit(). Nella chiamata allo EndInit(), verificare lo stato dell'istanza. Se non è correttamente inizializzato, puoi lanciare un InvalidOperationException. Se gli utenti tentano di utilizzare la tua istanza prima di essere inizializzata, invierai la tua NotInitializedException.

È un po 'più di lavoro, ma il vantaggio è che si sta creando un "pozzo di successo" più ampio per i propri utenti, assicurando che utilizzino correttamente le classi non riuscendo in modo rapido e precoce e dalla definizione stessa del proprio tipo (l'interfaccia è abbastanza chiara su quello che ti aspetti). Ti dà anche più "spazio", per così dire, per documentare come la tua classe dovrebbe essere usata.

Answer 8

Guardando il codice fornito e non sapendo nulla delle ipotesi di progettazione, direi che non si dovrebbe testare obj == null e lasciare che il framework lanci un NullReferenceException. Allora perché vuoi questo test? Una ragione per cui potrei pensare è che vuoi avere un messaggio di errore più significativo per il debug, ma dovresti usare Debug.Assert(obj != null, "Your message here").