Perché C # ti consente di "lanciare null"?

Durante la scrittura di un codice particolarmente complesso per la gestione delle eccezioni, qualcuno ha chiesto, non è necessario assicurarsi che l'oggetto eccezione non sia nullo? E ho detto, ovviamente no, ma poi ho deciso di provarlo. Apparentemente, puoi lanciare null, ma è ancora trasformato in un'eccezione da qualche parte.

Perché è permesso?

throw null;

In questo frammento, per fortuna "ex" non è nullo, ma potrebbe mai esserlo?

try
{
  throw null;
}
catch (Exception ex)
{
  //can ex ever be null?

  //thankfully, it isn't null, but is
  //ex is System.NullReferenceException
}

Perché la specifica del linguaggio richiede un'espressione di tipo System.Exception(quindi nullè valida in quel contesto) e non limita questa espressione a non essere nulla. In generale, non è possibile rilevare se il valore di quell'espressione è nullo meno. Dovrebbe risolvere il problema dell'arresto. Il runtime dovrà nullcomunque occuparsi del caso. Vedere:

Exception ex = null;
if (conditionThatDependsOnSomeInput) 
    ex = new Exception();
throw ex; 

Potrebbero, ovviamente, rendere nullinvalido il caso specifico di gettare il letterale, ma ciò non aiuterebbe molto, quindi perché sprecare lo spazio delle specifiche e ridurre la coerenza con poco vantaggio?

_{Disclaimer (prima di essere schiaffeggiato da Eric Lippert): questa è la mia speculazione sul ragionamento alla base di questa decisione progettuale. Ovviamente non ho partecipato alla riunione di progettazione;)}

La risposta alla tua seconda domanda, se una variabile di espressione catturata all'interno di una clausola catch può mai essere nulla: mentre la specifica C # nullnon dice se altri linguaggi possono causare la propagazione di un'eccezione, definisce il modo in cui vengono propagate le eccezioni:

Le clausole catch, se presenti, vengono esaminate in ordine di apparizione per individuare un gestore adatto per l'eccezione. La prima clausola catch che specifica il tipo di eccezione o un tipo di base del tipo di eccezione è considerata una corrispondenza. Una clausola catch generale è considerata una corrispondenza per qualsiasi tipo di eccezione. [...]

Perché nulll'affermazione in grassetto è falsa. Quindi, sebbene basandosi esclusivamente su ciò che dice la specifica C #, non possiamo dire che il runtime sottostante non genererà mai null, possiamo essere sicuri che anche se questo è il caso, sarà gestito solo dalla catch {}clausola generica .

Per le implementazioni C # sulla CLI, possiamo fare riferimento alla specifica ECMA 335. Quel documento definisce tutte le eccezioni che la CLI genera internamente (nessuna delle quali lo è null) e menziona che gli oggetti eccezione definiti dall'utente vengono lanciati throwdall'istruzione. La descrizione di tale istruzione è praticamente identica all'istruzione C # throw(tranne per il fatto che non limita il tipo di oggetto a System.Exception):

Descrizione:

L' throwistruzione lancia l'oggetto eccezione (tipo O) sullo stack e svuota lo stack. Per i dettagli sul meccanismo di eccezione, vedere la partizione I.
[Nota: sebbene la CLI consenta il lancio di qualsiasi oggetto, la CLS descrive una classe di eccezione specifica che deve essere utilizzata per l'interoperabilità del linguaggio. nota finale]

Eccezioni:

System.NullReferenceExceptionviene lanciato se objè null.

Correttezza:

Il CIL corretto garantisce che l'oggetto sia sempre nullo un riferimento a un oggetto (cioè di tipo O).

Credo che questi siano sufficienti per concludere che le eccezioni colte non lo sono mai null.

Apparentemente, puoi lanciare null, ma è ancora trasformato in un'eccezione da qualche parte.

Il tentativo di lanciare un nulloggetto produce un'eccezione di riferimento nullo (completamente non correlata).

Chiedere perché ti è permesso lanciare nullè come chiedere perché ti è permesso farlo:

object o = null;
o.ToString();

Tratto da qui :

Se usi questa espressione nel codice C #, verrà generata un'eccezione NullReferenceException. Questo perché l'istruzione throw richiede un oggetto di tipo Exception come singolo parametro. Ma questo stesso oggetto è nullo nel mio esempio.

Anche se potrebbe non essere possibile lanciare null in C # perché il lancio lo rileverà e lo trasformerà in un'eccezione NullReferenceException, È possibile ricevere null ... Mi capita di riceverlo proprio ora, il che causa la mia cattura (che non era aspettandosi che 'ex' sia nullo) per sperimentare un'eccezione di riferimento nullo che quindi si traduce nella morte della mia app (poiché quella era l'ultima cattura).

Quindi, anche se non possiamo lanciare null da C #, il netherworld può lanciare null, quindi la tua cattura più esterna (eccezione ex) è meglio essere preparati a riceverla. Solo FYI.

Penso che forse non puoi - quando provi a lanciare null, non può, quindi fa quello che dovrebbe in un caso di errore, che è un'eccezione di riferimento null. Quindi non stai effettivamente lanciando il null, non stai riuscendo a lanciare il null, il che si traduce in un lancio.

Cercando di rispondere "..per fortuna 'ex' non è nullo, ma potrebbe mai esserlo?":

Poiché probabilmente non possiamo generare eccezioni nulle, una clausola catch non dovrà mai rilevare un'eccezione nullo. Quindi, ex non potrebbe mai essere nullo.

Vedo ora che questa domanda in effetti è già stata posta .

Ricorda che un'eccezione include dettagli su dove viene generata l'eccezione. Visto che il costruttore non ha idea di dove debba essere lanciato, ha senso solo che il metodo throw inietti quei dettagli nell'oggetto nel punto in cui si trova il lancio. In altre parole, il CLR sta tentando di iniettare dati in null, il che attiva un'eccezione NullReferenceException.

Non sono sicuro che sia esattamente ciò che sta accadendo, ma spiega il fenomeno.

Supponendo che questo sia vero (e non riesco a pensare a un modo migliore per far sì che ex sia nullo rispetto a lanciare null;), ciò significherebbe che ex non può essere nullo.

Nelle versioni precedenti di c #:

Considera questa sintassi:

public void Add<T> ( T item ) => throw (hashSet.Add ( item ) ? null : new Exception ( "The item already exists" ));

Penso che sia molto più breve di questo:

public void Add<T> ( T item )
{
    if (!hashSet.Add ( item ))
        throw new Exception ( "The item already exists" );
}