Чому C # дозволяє вам "кидати нуль"?

Під час написання якогось особливо складного коду обробки винятків хтось запитав, чи не потрібно переконуватись, що об’єкт винятку не має значення null? І я сказав, звичайно, ні, але потім вирішив спробувати. Мабуть, ви можете кинути нуль, але це все одно десь перетворено на виняток.

Чому це дозволено?

throw null;

У цьому фрагменті, на щастя, "колишній" не є нульовим, але чи може він бути коли-небудь?

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

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

Оскільки специфікація мови очікує там виразу типу System.Exception(отже, nullє допустимим у цьому контексті) і не обмежує цей вираз ненульовим. Загалом, жодним чином він не може визначити, чи є значення цього виразу nullчи ні. Це повинно було б вирішити проблему зупинки. Виконавцю все nullодно доведеться розібратися зі справою. Подивитися:

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

Звичайно, вони могли б зробити конкретний випадок викидання nullлітералу недійсним, але це не допомогло б, то навіщо витрачати специфікаційний простір і зменшувати узгодженість з малою користю?

_{Застереження (до того, як Ерік Ліпперт отримає мене ляпас): Це моє власне припущення щодо міркувань, що лежать в основі цього дизайнерського рішення. Звичайно, я не був на зустрічі дизайнерів;)}

Відповідь на ваше друге запитання, чи може змінна виразу, зафіксована в реченні catch, коли-небудь бути нульовою: Хоча специфікація C # мовчить про те, чи можуть інші мови спричинити nullрозповсюдження винятку, вона визначає спосіб розповсюдження винятків:

Застереження про вилов, якщо такі є, перевіряються з метою виявлення відповідного обробника для виключення. Перше речення catch, яке вказує тип виключення або базовий тип типу виключення , вважається збігом. Загальне речення catch вважається збігом для будь-якого типу винятків. [...]

Адже nullжирне твердження хибне. Отже, хоча суто на основі того, що сказано в специфікації C #, ми не можемо сказати, що основний час виконання ніколи не буде видавати null, ми можемо бути впевнені, що навіть якщо це так, це буде оброблятися лише загальним catch {}реченням.

Для реалізацій C # на CLI ми можемо посилатися на специфікацію ECMA 335. Цей документ визначає всі винятки, які CLI створює внутрішньо (жоден з них не є null), і згадує, що визначені користувачем об'єкти винятків видаються throwінструкцією. Опис цієї інструкції практично ідентичний інструкції C # throw(за винятком того, що він не обмежує тип об'єкта System.Exception):

Опис:

throwІнструкція кидає об'єкт виключення (типу O) в стеку і спустошує стек. Детальніше про механізм винятків див. У розділі I.
[Примітка: Хоча CLI дозволяє будь-який об’єкт, який буде кинуто, CLS описує конкретний клас винятків, який повинен використовуватися для мовної сумісності. кінцева примітка]

Винятки:

System.NullReferenceExceptionкидається, якщо objє null.

Правильність:

Правильний CIL гарантує, що об'єкт завжди є nullабо посиланням на об'єкт (тобто типу O).

Я вважаю, що цього достатньо, щоб зробити висновок, що вилучених випадків ніколи не буває null.

Мабуть, ви можете кинути нуль, але це все одно десь перетворено на виняток.

Спроба кинути nullоб’єкт призводить до (повністю не пов’язаного) нульового виключення посилань.

Запитати, чому вам дозволено кидати, nullвсе одно, що запитати, чому вам це дозволено:

object o = null;
o.ToString();

Взято звідси :

Якщо ви використовуєте цей вираз у коді C #, він видасть NullReferenceException. Це тому, що оператору throw потрібен об’єкт типу Exception як єдиний параметр. Але саме цей об'єкт є нульовим у моєму прикладі.

Незважаючи на те, що в C # може бути неможливо кинути null, оскільки кидок виявить це і перетворить його на NullReferenceException, Є можливість отримати null ... Я випадково отримую це прямо зараз, що спричиняє мій улов (який не був очікуючи, що `` ex '' буде нульовим) матиме виняток нульового посилання, який потім призведе до того, що мій додаток помре (оскільки це був останній улов).

Отже, хоча ми не можемо викинути нуль із C #, потойбіччя може скинути нуль, тому ваш крайній улов (Виняток ex) краще бути готовим отримати його. Просто FYI.

Я думаю, можливо, ви не можете - коли ви намагаєтесь кинути null, це не може, тому він робить те, що має, у випадку помилки, тобто викидання нульового виключення посилання. Отже, ви насправді не кидаєте нуль, вам не вдається кинути нуль, що призводить до кидка.

Намагання відповісти "..з вдячністю" колишній "не є нульовим, але чи може це бути коли-небудь?":

Оскільки ми, безперечно, не можемо викидати винятки, які є нульовими, речення catch також ніколи не доведеться ловити виняток, який є нульовим. Таким чином, ex ніколи не може бути нулем.

Зараз я бачу, що це питання насправді вже було задано .

Пам’ятайте, що виняток включає деталі щодо того, куди кинуто виняток. Вбачаючи, що конструктор не має уявлення, куди його потрібно кинути, тоді має сенс лише те, що метод throw вводить ці деталі в об'єкт у точці, в якій знаходиться метання. Іншими словами, CLR намагається ввести дані в null, що викликає NullReferenceException.

Не впевнений, що це саме те, що відбувається, але це пояснює явище.

Якщо припустити, що це правда (і я не можу придумати кращого способу отримати ex як null, ніж throw null;), це означало б, що ex не може бути null.

У старішому c #:

Розглянемо цей синтаксис:

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

Я думаю, це набагато коротше:

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