У C # чи є якісь вагомі причини (крім кращого повідомлення про помилку) для додавання перевірки null параметрів до кожної функції, де null не є допустимим значенням? Очевидно, що код, який використовує s, все одно видасть виняток. І такі перевірки роблять код повільнішим та важчим у обслуговуванні.
void f(SomeType s)
{
if (s == null)
{
throw new ArgumentNullException("s cannot be null.");
}
// Use s
}
Відповіді:
Так, є вагомі причини:
NullReferenceExceptionЩодо ваших заперечень:
І на ваше твердження:
Очевидно, що код, який використовує s, все одно видасть виняток.
Справді? Розглянемо:
void f(SomeType s)
{
// Use s
Console.WriteLine("I've got a message of {0}", s);
}
Це використовує s, але не створює винятку. Якщо недійсним sє значення null, і це вказує на те, що щось не так, виняток є найбільш підходящою поведінкою тут.
Тепер, де ви розміщуєте ці перевірки перевірки аргументів, це інша справа. Ви можете вирішити довіряти коду у вашому власному класі, тому не турбуйтеся про приватні методи. Ви можете вирішити довіряти решті збірки, тому не турбуйтеся про внутрішні методи. Ви майже напевно повинні перевірити аргументи для загальнодоступних методів.
Побічна примітка: перевантаження конструктора з одним параметром ArgumentNullExceptionмає бути просто іменем параметра, тому ваш тест повинен бути:
if (s == null)
{
throw new ArgumentNullException("s");
}
Крім того, ви можете створити метод розширення, дозволяючи дещо лаконічніше:
s.ThrowIfNull("s");
У моїй версії (загального) методу розширення я змушую його повертати початкове значення, якщо воно не є нульовим, що дозволяє писати такі речі:
this.name = name.ThrowIfNull("name");
Ви також можете мати перевантаження, яке не приймає імені параметра, якщо вас це не надто турбує.
ThrowIfEmptyнаICollection
Debug.Assert. Ще важливіше виявити помилки у виробництві (до того, як вони зіпсують реальні дані), ніж у розробці.
throw new ArgumentNullException(nameof(s))
Я погоджуюся з Джоном, але я додав би до цього одне.
Моє ставлення до того, коли додавати явні перевірки на нуль, базується на таких передумовах:
throwвисловлювання є висловлювання .ifє твердження .throwвif (x == null) throw whatever;Якщо немає ніякої можливості для цього оператор буде виконуватися , то він не може бути перевірений і повинен бути замінений Debug.Assert(x != null);.
Якщо існує можливий спосіб виконання цього твердження, напишіть його, а потім напишіть модульний тест, який його виконує.
Це особливо важливо , щоб державні методи громадських типів перевірити свої аргументи таким чином; Ви навіть не уявляєте, яку божевільну штуку збираються робити ваші користувачі. Дайте їм "привіт вам, кісточко, ви робите це неправильно!" виняток якомога швидше.
Навпаки, приватні методи приватних типів набагато частіше потрапляють у ситуацію, коли ви керуєте аргументами і можете мати надійну гарантію того, що аргумент ніколи не буде нульовим; використовувати твердження для документування такого інваріанта.
Без явної ifперевірки може бути дуже важко зрозуміти, що було, nullякщо ви не володієте кодом.
Якщо ви потрапили NullReferenceExceptionз глибокої бібліотеки без вихідного коду, то, швидше за все, у вас буде багато проблем з роз’ясненням, що ви зробили неправильно.
Ці ifперевірки не дозволять зробити ваш код помітно повільнішим.
Зверніть увагу, що параметром ArgumentNullExceptionконструктора є ім'я параметра, а не повідомлення.
Ваш код повинен бути
if (s == null) throw new ArgumentNullException("s");
Я написав фрагмент коду, щоб полегшити це:
<?xml version="1.0" encoding="utf-8" ?>
<CodeSnippets xmlns="http://schemas.microsoft.com/VisualStudio/2005/CodeSnippet">
<CodeSnippet Format="1.0.0">
<Header>
<Title>Check for null arguments</Title>
<Shortcut>tna</Shortcut>
<Description>Code snippet for throw new ArgumentNullException</Description>
<Author>SLaks</Author>
<SnippetTypes>
<SnippetType>Expansion</SnippetType>
<SnippetType>SurroundsWith</SnippetType>
</SnippetTypes>
</Header>
<Snippet>
<Declarations>
<Literal>
<ID>Parameter</ID>
<ToolTip>Paremeter to check for null</ToolTip>
<Default>value</Default>
</Literal>
</Declarations>
<Code Language="csharp"><![CDATA[if ($Parameter$ == null) throw new ArgumentNullException("$Parameter$");
$end$]]>
</Code>
</Snippet>
</CodeSnippet>
</CodeSnippets>
Можливо, ви захочете поглянути на кодові контракти, якщо вам потрібен більш приємний спосіб переконатися, що ви не отримуєте будь-які нульові об'єкти як параметр.
Головна перевага полягає в тому, що ви з самого початку чітко відповідаєте вимогам свого методу. Це дає зрозуміти іншим розробникам, що працюють над кодом, що виклик справді помилково надсилає нульове значення до вашого методу.
Перевірка також зупинить виконання методу до виконання будь-якого іншого коду. Це означає, що вам не доведеться турбуватися про модифікації, внесені незавершеним методом.
Це економить деякі налагодження, коли ви натискаєте цей виняток.
ArgumentNullException чітко зазначає, що значення "s" було нульовим.
Якщо у вас немає такої перевірки, і ви дозволите коду дістати, ви отримаєте NullReferenceException з якогось невідомого рядка в цьому методі. У збірці випуску ви не отримуєте номерів рядків!
Оригінальний код:
void f(SomeType s)
{
if (s == null)
{
throw new ArgumentNullException("s cannot be null.");
}
// Use s
}
Перепишіть як:
void f(SomeType s)
{
if (s == null) throw new ArgumentNullException(nameof(s));
}
[Редагувати] Причина перезапису з використанням nameofполягає в тому, що це дозволяє спростити рефакторинг. Якщо ім'я вашої змінної sколи-небудь змінюється, тоді повідомлення про налагодження також будуть оновлені, тоді як якщо ви просто вкажете ім'я змінної, тоді воно з часом буде застарілим, коли оновлення з часом будуть зроблені. Це хороша практика, яка використовується в промисловості.
int i = Age ?? 0;
Отже, для вашого прикладу:
if (age == null || age == 0)
Або:
if (age.GetValueOrDefault(0) == 0)
Або:
if ((age ?? 0) == 0)
Або потрійний:
int i = age.HasValue ? age.Value : 0;