Dlaczego C # pozwala na „rzucanie null”?

Podczas pisania jakiegoś szczególnie złożonego kodu obsługi wyjątków ktoś zapytał, czy nie musisz się upewnić, że obiekt wyjątku nie jest null? Odpowiedziałem, że oczywiście nie, ale zdecydowałem się spróbować. Najwyraźniej możesz zgłosić null, ale nadal jest gdzieś zamieniony w wyjątek.

Dlaczego jest to dozwolone?

throw null;

W tym fragmencie na szczęście „ex” nie jest zerowe, ale czy kiedykolwiek mogło tak być?

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

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

Ponieważ specyfikacja języka oczekuje tam wyrażenia typu System.Exception(w związku z tym nulljest poprawna w tym kontekście) i nie ogranicza tego wyrażenia do wartości innej niż null. Ogólnie rzecz biorąc, nie ma możliwości wykrycia, czy wartość tego wyrażenia jest, nullczy nie. Musiałby rozwiązać problem zatrzymania. Środowisko wykonawcze i tak będzie musiało zająć się nullsprawą. Widzieć:

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

Mogliby oczywiście uczynić konkretny przypadek odrzucenia nulldosłownego nieważnym, ale to niewiele by pomogło, więc po co marnować miejsce na specyfikację i zmniejszać spójność z niewielkimi korzyściami?

_{Zastrzeżenie (zanim zostanie uderzony przez Erica Lipperta): To jest moja własna spekulacja na temat uzasadnienia tej decyzji projektowej. Oczywiście nie byłem na spotkaniu projektowym;)}

Odpowiedź na drugie pytanie, czy zmienna wyrażenia przechwycona w klauzuli catch może kiedykolwiek mieć wartość null: Podczas gdy specyfikacja C # milczy na temat tego, czy inne języki mogą powodować nullpropagowanie wyjątku, definiuje sposób propagowania wyjątków:

Klauzule catch, jeśli istnieją, są sprawdzane w kolejności pojawiania się, aby zlokalizować odpowiednią procedurę obsługi wyjątku. Pierwsza klauzula catch, która określa typ wyjątku lub typ podstawowy typu wyjątku, jest uważana za dopasowanie. Ogólna klauzula catch jest uważana za dopasowanie dla dowolnego typu wyjątku. […]

Bo nullpogrubione stwierdzenie jest fałszywe. Tak więc, chociaż opiera się wyłącznie na tym, co mówi specyfikacja C #, nie możemy powiedzieć, że bazowe środowisko wykonawcze nigdy nie zwróci wartości null, możemy być pewni, że nawet jeśli tak jest, będzie to obsługiwane tylko przez catch {}klauzulę ogólną .

W przypadku implementacji języka C # w interfejsie CLI możemy odwołać się do specyfikacji ECMA 335. Ten dokument definiuje wszystkie wyjątki, które CLI zgłasza wewnętrznie (z których żaden nie jest null) i wspomina, że ​​obiekty wyjątków zdefiniowane przez użytkownika są generowane przez throwinstrukcję. Opis tej instrukcji jest praktycznie identyczny z throwinstrukcją C # (z wyjątkiem tego, że nie ogranicza typu obiektu do System.Exception):

Opis:

throwInstrukcja zgłasza wyjątek (typ obiektu O) w stos i opróżnia stos. Aby uzyskać szczegółowe informacje na temat mechanizmu wyjątków, patrz Partycja I.
[Uwaga: Podczas gdy CLI pozwala na wyrzucenie dowolnego obiektu, CLS opisuje konkretną klasę wyjątku, która powinna być używana do współdziałania języków. notatka końcowa]

Wyjątki:

System.NullReferenceExceptionjest wyrzucany, jeśli objjest null.

Poprawność:

Prawidłowy CIL zapewnia, że ​​obiekt jest zawsze albo nullodwołaniem do obiektu (tj. Typu O).

Uważam, że są one wystarczające, aby stwierdzić, że wychwycone wyjątki nigdy nie są null.

Najwyraźniej możesz zgłosić null, ale nadal jest gdzieś zamieniony w wyjątek.

Próba rzucenia nullobiektu powoduje (całkowicie niepowiązany) wyjątek odwołania zerowego.

Pytanie, dlaczego możesz rzucać, nulljest jak pytanie, dlaczego możesz to zrobić:

object o = null;
o.ToString();

Zaczerpnięte stąd :

Jeśli użyjesz tego wyrażenia w kodzie C #, spowoduje to zgłoszenie wyjątku NullReferenceException. Dzieje się tak, ponieważ instrukcja rzucania wymaga obiektu typu Exception jako pojedynczego parametru. Ale ten sam obiekt jest pusty w moim przykładzie.

Chociaż może nie być możliwe zgłoszenie wartości null w C #, ponieważ rzut wykryje to i przekształci go w wyjątek NullReferenceException, JEST możliwe, aby otrzymać wartość null ... Tak się składa, że ​​otrzymuję to teraz, co powoduje mój catch (który nie był Oczekiwanie, że `` ex '' ma wartość null), aby doświadczyć zerowego wyjątku odniesienia, który następnie powoduje śmierć mojej aplikacji (ponieważ był to ostatni przechwycenie).

Tak więc, chociaż nie możemy wyrzucić null z C #, zaświat może zgłosić wartość null, więc twój najbardziej zewnętrzny catch (Exception ex) lepiej przygotuj się na jego otrzymanie. Po prostu FYI.

Myślę, że może nie możesz - kiedy próbujesz rzucić null, nie może, więc robi to, co powinien w przypadku błędu, czyli rzuca zerowy wyjątek odwołania. Więc tak naprawdę nie wyrzucasz null, nie możesz wyrzucić null, co powoduje rzut.

Próba odpowiedzi „… na szczęście„ ex ”nie jest zerowa, ale czy kiedykolwiek mogłaby tak być?”:

Ponieważ prawdopodobnie nie możemy zgłosić wyjątków, które są zerowe, klauzula catch również nigdy nie będzie musiała przechwytywać wyjątku, który jest pusty. Tak więc ex nigdy nie może być zerowy.

Teraz widzę, że to pytanie faktycznie zostało już zadane .

Pamiętaj, że wyjątek zawiera szczegółowe informacje o tym, gdzie został zgłoszony. Biorąc pod uwagę, że konstruktor nie ma pojęcia, gdzie ma zostać rzucony, ma sens tylko to, że metoda rzucania wprowadza te szczegóły do ​​obiektu w miejscu, w którym znajduje się rzut. Innymi słowy, środowisko CLR próbuje wstrzyknąć dane do wartości null, co wyzwala NullReferenceException.

Nie jestem pewien, czy tak właśnie się dzieje, ale wyjaśnia to zjawisko.

Zakładając, że to prawda (i nie mogę wymyślić lepszego sposobu, aby ex był zerowy, niż rzucanie null;), oznaczałoby to, że ex nie może być zerowy.

W starszym C #:

Rozważ tę składnię:

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

Myślę, że jest o wiele krótszy niż to:

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