Якщо функції повинні зробити нульові перевірки перед тим, як виконати задумане поведінку, це погана конструкція?

Тому я не знаю, чи це добре, чи погано дизайн коду, тому я подумав, що краще запитати.

Я часто створюю методи, що займаються обробкою даних за участю класів, і я часто роблю багато перевірок у методах, щоб переконатися, що я не отримую нульових посилань або інших помилок перед рукою.

Для дуже базового прикладу:

// fields and properties
private Entity _someEntity;
public Entity SomeEntity => _someEntity;

public void AssignEntity(Entity entity){
    _someEntity = entity;
}
public void SetName(string name)
{
    if (_someEntity == null) return; //check to avoid null ref
    _someEntity.Name = name;
    label.SetText(_someEntity.Name);
}

Отже, як ви можете бачити щоразу перевірку нуля. Але чи повинен метод не мати цієї перевірки?

Наприклад, чи повинен зовнішній код очистити дані перед рукою, щоб методи не потребували перевірки, як показано нижче:

 if(entity != null) // this makes the null checks redundant in the methods
 {
     Manager.AssignEntity(entity);
     Manager.SetName("Test");
 }

Якщо підсумовувати, чи повинні методи "перевірити дані", а потім зробити їх обробку даних, чи це слід гарантувати перед тим, як викликати метод, і якщо ви не отримаєте перевірку перед викликом методу, він повинен видати помилку (або зафіксувати запит помилка)?

Проблема з вашим основним прикладом - це не нульова перевірка, це тиха помилка .

Помилки нуля вказівника / посилання, частіше за все, є помилками програміста. Помилки програміста найчастіше найкраще усунути, якщо негайно і голосно виходять з ладу. У вас є три загальних способи вирішити проблему в цій ситуації:

1. Не турбуйтеся перевіряти, а лише дозвольте виконувати час виключення nullpointer.
2. Перевірте і викиньте виняток із повідомленням, що краще, ніж основне повідомлення NPE.

Третє рішення - це більше роботи, але набагато надійніше:

3. Структуруйте свій клас таким чином, щоб практично неможливо _someEntityбуло колись перебувати в недійсному стані. Один із способів зробити це - позбутися AssignEntityі вимагати цього як параметра для інстанції. Інші методи ін'єкційних залежностей можуть бути також корисними.

У деяких ситуаціях є сенс перевірити всі аргументи функції на достовірність перед будь-якою роботою, яку ви виконуєте, а в інших має сенс сказати абоненту, що він несе відповідальність за те, щоб їх введення були дійсними, а не перевіряли. Який кінець спектра ви будете залежати від вашої проблемної області. Третій варіант має істотну перевагу в тому, що ви можете, в певній мірі, змусити компілятор домогтися того, щоб абонент все робив правильно.

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

Оскільки _someEntityйого можна модифікувати на будь-якій стадії, то має сенс перевіряти її щоразу, коли SetNameвикликається. Зрештою, це могло змінитись з останнього разу, коли цей метод називався. Але майте на увазі, що код в SetNameне є безпечним для потоків, тому ви можете виконати цю перевірку в одному потоці, _someEntityвстановленому nullіншим, і тоді код буде NullReferenceExceptionвсе-таки барф .

Один із підходів до цієї проблеми полягає в тому, щоб стати ще більш захисними і зробити одне з наступних:

1. зробити локальну копію _someEntityта посилатися на цю копію методом,
2. використовуйте замок навколо, _someEntityщоб переконатися, що він не змінюється під час виконання методу,
3. використовувати a try/catchі виконувати ті самі дії, NullReferenceExceptionщо виникають у методі, як ви виконувались у початковій нульовій перевірці (у цьому випадку nopдії).

Але те, що ви насправді повинні зробити, це зупинитись і задати собі питання: чи вам насправді потрібно дозволити _someEntityперезаписати? Чому б не встановити його один раз через конструктор. Таким чином, вам потрібно лише один раз зробити цю нульову перевірку:

private readonly Entity _someEntity;

public Constructor(Entity someEntity)
{
    if (someEntity == null) throw new ArgumentNullException(nameof(someEntity));
    _someEntity = someEntity;
}

public void SetName(string name)
{
    _someEntity.Name = name;
    label.SetText(_someEntity.Name);
}

Якщо це взагалі можливо, я рекомендую використовувати такий підхід у таких ситуаціях. Якщо ви не можете пам’ятати про безпеку ниток, вибираючи, як обробити можливі нулі.

Як бонусний коментар, я вважаю, що ваш код дивний і його можна вдосконалити. Всі:

private Entity _someEntity;
public Entity SomeEntity => _someEntity;

public void AssignEntity(Entity entity){
    _someEntity = entity;
}

можна замінити на:

public Entity SomeEntity { get; set; }

Що має той самий функціонал, за винятком того, що ви можете встановити поле за допомогою налаштування властивостей, а не метод з іншим ім'ям.

Але чи повинен метод не мати цієї перевірки?

Це ваш вибір.

Створюючи publicметод, ви пропонуєте громадськості можливість його зателефонувати. Це завжди поєднується з неявним договором про те, як викликати цей метод і що чекати, коли це робити. Цей контракт може (або не може) містити " так, е-е, якщо ви перейдете nullяк значення параметра, воно вибухне прямо у вашому обличчі ". Іншими частинами цього договору можуть бути " о, BTW: кожного разу, коли дві нитки одночасно виконують цей метод, кошеня гине ".

Який тип контракту ви хочете скласти, залежить від вас. Важливі речі - це

• створити корисний та послідовний API та

• це добре задокументувати, особливо для тих крайових справ.

Які ймовірні випадки виклику вашого методу?

Інші відповіді хороші; Я хотів би поширити їх, зробивши кілька коментарів щодо модифікаторів доступності. По-перше, що робити, якщо nullце ніколи не дійсно:

• публічні та захищені методи - це ті, де ви не контролюєте абонента. Вони повинні кидати, коли пройде нуль. Таким чином ви навчаєте своїх абонентів ніколи не передавати вам нуль, оскільки вони хотіли б, щоб їх програма не вийшла з ладу.

• внутрішні і приватні методи є ті , де ви дійсно контролювати абонент. Вони повинні стверджувати, коли пропущено нуль; вони, ймовірно, згодом вийдуть з ладу, але принаймні, ви спочатку отримали твердження та можливість прорватися до налагоджувача. Знову ж таки, ви хочете навчити своїх абонентів правильно телефонувати, завдаючи їм боляче, коли вони цього не роблять.

Тепер, що ви робите, якщо це може бути дійсним для передачі нуля? Я б уникнув цієї ситуації з нульовим шаблоном об'єкта . Тобто: зробіть спеціальний екземпляр типу та вимагайте, щоб він використовувався будь-коли, коли потрібен недійсний об’єкт . Тепер ви повернулися в приємний світ метання / затвердження кожного використання нуля.

Наприклад, ви не хочете опинятися в такій ситуації:

class Person { ... }
...
class ExpenseReport { 
  public void SubmitReport(Person approver) { 
    if (approver == null) ... do something ...

та на сайті виклику:

// I guess this works but I don't know what it means
expenses.SubmitReport(null); 

Оскільки (1) ви навчаєте своїх абонентів, що нуль є хорошим значенням, і (2) незрозуміло, що таке семантика цього значення. Швидше зробіть це:

class ExpenseReport { 
  public static readonly Person ApproverNotRequired = new Person();
  public static readonly Person ApproverUnknown = new Person();
  ...
  public void SubmitReport(Person approver) { 
    if (approver == null) throw ...
    if (approver == ApproverNotRequired) ... do something ...
    if (approver == ApproverUnknown) ... do something ...

А тепер сайт виклику виглядає приблизно так:

expenses.SubmitReport(ExpenseReport.ApproverNotRequired);

і тепер читач коду знає, що це означає.

Інші відповіді вказують, що ваш код можна очистити, щоб не потрібна перевірка нуля, де він у вас є, однак для загальної відповіді про те, чим може бути корисна перевірка на нуль, розглянемо наступний зразок коду:

public static class Foo {
    public static void Frob(Bar a, Bar b) {
        if (a == null) throw new ArgumentNullException(nameof(a));
        if (b == null) throw new ArgumentNullException(nameof(b));

        a.Something = b.Something;
    }
}

Це дає перевагу в обслуговуванні. Якщо у вашому коді колись виникає дефект, коли щось передає нульовий об'єкт методу, ви отримаєте корисну інформацію від методу щодо того, який параметр був нульовим. Без чеків ви отримаєте NullReferenceException у рядку:

a.Something = b.Something;

І (враховуючи, що властивість Something є типовим типом) або a, або b може бути нульовим, і ви не зможете дізнатися, який із сліду стека. За допомогою чеків ви точно дізнаєтесь, який об’єкт був нульовим, що може бути надзвичайно корисно при спробі відібрати дефект.

Зауважу, що шаблон у вашому оригінальному коді:

if (x == null) return;

Може використовувати його за певних обставин, це може також (можливо частіше) дати вам дуже хороший спосіб маскування основних проблем у вашій базі коду.

Ні взагалі, але це залежить.

Ви робите нульову перевірку, якщо ви хочете на неї реагувати.

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

Якщо ви не зробите нульову перевірку посилань (або викинете неперевірений виняток), вона може викинути невірно NullReferenceException, що зазвичай не обробляється користувачем методу і навіть може закрити програму. Це означає, що функція, очевидно, повністю не зрозуміла, а тому програма несправна.

Щось розширення для відповіді @ null, але, на моєму досвіді, робити недійсні перевірки незалежно від того.

Хороше захисне програмування - це ставлення до того, що ви кодуєте поточну процедуру окремо, за умови, що вся решта програми намагається її розбити. Коли ви пишете критичний код місії, коли невдача не є варіантом, це майже єдиний шлях.

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

Якщо nullє прийнятним значенням, наприклад, будь-який з другого по п'ятий параметри для MSVC звичайного _splitpath (), то мовчки мати справу з ним - це правильна поведінка.

Якщо nullніколи не трапляється під час виклику відповідної рутини, тобто у випадку з ОП, контракт API AssignEntity()повинен бути викликаний дійсним, Entityтоді викиньте виняток, або іншим чином не вдасться забезпечити багато шуму в процесі.

Ніколи не турбуйтеся про вартість нульової перевірки, вони забруднені дешевим, якщо вони трапляться, а при сучасних компіляторах статичний аналіз коду може і повністю їх уникне, якщо компілятор визначить, що цього не відбудеться.