Я чув, як говорилося, що включення нульових посилань у мови програмування є "помилкою в мільярд доларів". Але чому? Звичайно, вони можуть викликати NullReferenceExceptions, але що робити? Будь-який елемент мови може бути джерелом помилок при неправильному використанні.

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

Customer c = Customer.GetByLastName("Goodman"); // returns null if not found
if (c != null)
{
    Console.WriteLine(c.FirstName + " " + c.LastName + " is awesome!");
}
else { Console.WriteLine("There was no customer named Goodman.  How lame!"); }

Можна сказати так:

if (Customer.ExistsWithLastName("Goodman"))
{
    Customer c = Customer.GetByLastName("Goodman") // throws error if not found
    Console.WriteLine(c.FirstName + " " + c.LastName + " is awesome!"); 
}
else { Console.WriteLine("There was no customer named Goodman.  How lame!"); }

Але як це краще? У будь-якому випадку, якщо ви забудете перевірити наявність клієнта, ви отримаєте виняток.

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

null - зло

Існує уявлення про InfoQ по цій темі: Null Посилання: мільярд доларів Mistake від Тоні Хоара

Тип опції

Альтернативою функціонального програмування є використання типу Option , який може містити SOME valueабо NONE.

Хороша стаття "Варіант" Шаблон, який обговорює тип Варіант та забезпечує його реалізацію для Java.

Я також знайшов звіт про помилки для Java щодо цієї проблеми: Додайте типи параметрів Nice в Java, щоб запобігти NullPointerExceptions . Запрошення функція була введена в Java 8.

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

Ви маєте рацію, що витончена робота з помилками може бути функціонально ідентичною ifзаявам, що перевіряють нуль . Але що відбувається, коли те, що ви переконали в собі, не може бути нульовим, насправді є нульовим? Кербум. Що б далі не було, я готовий зробити ставку, що 1) це не буде витончено і 2) вам не сподобається.

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

Існує кілька проблем із використанням нульових посилань у коді.

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

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

По-третє, нульові посилання вносять додаткові кодові шляхи для тестування .

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

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

Чому б не скористатися шаблоном NullObject, щоб скористатися перевіркою виконання, щоб він посилався на методи NOP, характерні для цього стану (відповідно до інтерфейсу звичайного стану), а також усунув усі додаткові перевірки нульових посилань на всій вашій кодовій базі?

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

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

Customer? c = Customer.GetByLastName("Goodman");
// note the question mark -- 'c' is either a Customer or null
if (c != null)
{
    // c is not null, therefore its type in this block is
    // now 'Customer' instead of 'Customer?'
    Console.WriteLine(c.FirstName + " " + c.LastName + " is awesome!");
}
else { Console.WriteLine("There was no customer named Goodman.  How lame!"); }

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

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

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

Мета системи типу - забезпечити, щоб різні компоненти програми «добре поєднувалися» належним чином; добре набрана програма не може «вийти з рейок» у невизначене поведінку.

Розглянемо гіпотетичний діалект Java або будь-який улюблений у вас "Hello, world!"тип статичної мови, де ви можете призначити рядок будь-якій змінній будь-якого типу:

Foo foo1 = new Foo();  // Legal
Foo foo2 = "Hello, world!"; // Also legal
Foo foo3 = "Bonjour!"; // Not legal - only "Hello, world!" is allowed

І ви можете перевірити такі змінні:

if (foo1 != "Hello, world!") {
    bar(foo1);
} else {
    baz();
}

У цьому немає нічого неможливого - хтось міг розробити таку мову, якби хотів. Особливе значення не повинно бути "Hello, world!"- це , можливо, було число 42, кортеж (1, 4, 9), або, скажімо, null. Але чому б ти це робив? Змінна типу Fooповинна містити лише Foos - у цьому вся суть системи типів! nullце не Fooбільше, ніж "Hello, world!"є. Гірше - nullце не значення будь-якого типу, і ви нічого з цим не можете зробити!

Програміст ніколи не може бути впевнений, що змінна насправді містить a Foo, а також програма не може; щоб уникнути невизначеної поведінки, вона повинна перевірити змінні, "Hello, world!"перш ніж використовувати їх як Foos. Зауважте, що проведення перевірки рядків у попередньому фрагменті не поширює факту, що foo1 насправді є Foo- barймовірно, буде мати і свою перевірку, просто для безпеки.

Порівняйте це з використанням a Maybe/ Optiontype із узгодженням шаблону:

case maybeFoo of
 |  Just foo => bar(foo)
 |  Nothing => baz()

Всередині цього Just fooпункту і ви, і програма точно знаєте, що наша Maybe Fooзмінна дійсно містить Fooзначення - ця інформація поширюється вниз по ланцюгу викликів, і barне потрібно робити ніяких перевірок. Оскільки Maybe Fooце відмінний тип від Fooвас, ви змушені керуватись можливістю, яку він може містити Nothing, тому ви не зможете ніколи закрити сліпою a NullPointerException. Ви можете набагато легше міркувати про свою програму, і компілятор може опустити нульові перевірки, знаючи, що всі змінні типу Fooдійсно містять Foos. Всі перемагають.

(Кидаючи капелюх на ринг для старого питання;))

Специфічна проблема з null полягає в тому, що він порушує статичне введення тексту.

Якщо у мене є Thing t, то компілятор може гарантувати, що я можу зателефонувати t.doSomething(). Ну, UNLESS tнедійсний під час виконання. Тепер усі ставки відключені. Компілятор сказав, що це нормально, але я дізнаюся набагато пізніше, що tНЕ насправді doSomething(). Тому замість того, щоб мати можливість довіряти компілятору, щоб вловлювати помилки типу, я повинен зачекати, поки час виконання, щоб їх виловити. Я б також міг просто використовувати Python!

Тож у певному сенсі null вводить динамічне введення в статично типовану систему з очікуваними результатами.

Різниця між тим, що ділиться на нуль або лог від’ємника тощо, полягає в тому, що коли i = 0, це все ще є int. Компілятор все ще може гарантувати його тип. Проблема полягає в тому, що логіка неправильно застосовує це значення способом, який не дозволено логікою ... але якщо логіка робить це, це значною мірою визначення помилки.

(Компілятор може вирішити деякі з цих проблем, BTW. Як і позначення виразів, як i = 1 / 0під час компіляції. Але ви не можете реально розраховувати, що компілятор буде виконувати функцію і гарантувати, що параметри відповідають усім логіці функції)

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

Рядок s = новий цілий (1234);

То чому він повинен дозволяти присвоювати значення (null), яке порушує де-посилання на s?

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

nullПокажчик являє собою інструмент

не ворог. Ви просто повинні використовувати їх правильно.

Подумайте лише хвилину про те, скільки часу потрібно знайти та виправити типову недійсну помилку вказівника , порівняно з визначенням та виправленням нульової помилки вказівника. Легко перевірити покажчик на null. Це PITA, щоб перевірити, вказує чи ні ненульовий вказівник на дійсні дані.

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

Мораль історії: Не кидайте дітей водою. І не звинувачуйте інструменти в аварії. Людина, яка давно вигадала число нуль, була досить розумною, оскільки в той день можна було назвати «нічого». nullПокажчик не так далеко від цього.

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

• Довідка, що займає атрибут a NullObject(повинна, згідно з теорією), нічого не робить, коли викликається метод. Таким чином, тонкі помилки можуть бути введені через помилково непризначені посилання, які зараз гарантовано є ненульовими (так!), Але виконують небажані дії: нічого. З NPE - це очевидно, де проблема криється. З тим, NullObjectщо поводиться якось (але неправильно), ми вводимо ризик виявлення помилок (занадто) пізно. Це не випадково схоже на недійсну проблему вказівника і має подібні наслідки: Посилання вказує на щось, що схоже на дійсні дані, але це не так, вводить помилки даних і їх важко відстежити. Якщо чесно, я б у цих випадках віддав перевагу NPE, який не працює негайно,через логічну / помилку даних, яка раптом вдарить мене пізніше по дорозі. Пам’ятайте дослідження IBM про вартість помилок, які залежать від того, на якому етапі вони виявляються?

• Поняття нічого не робити, коли метод викликається на a NullObject, не втримується, коли виклик властивості або функція викликається, або коли метод повертає значення через out. Скажімо, повернене значення - це intі ми вирішуємо, що "нічого не робити" означає "повернути 0". Але як ми можемо бути впевнені, що 0 є правильним "нічого", яке потрібно (не) повертати? Зрештою, NullObjectне слід нічого робити, але коли його запитують про значення, воно має якось реагувати. Невдача не є варіантом: ми використовуємо NullObjectдля запобігання NPE, і ми точно не торгуватимемо його іншим винятком (не реалізовано, ділимо на нуль, ...), чи не так? То як правильно ви нічого не повертаєте, коли вам щось потрібно повернути?

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

Нульові посилання є помилкою, оскільки вони дозволяють нечуттєвий код:

foo = null
foo.bar()

Є альтернативи, якщо ви використовуєте систему типів:

Maybe<Foo> foo = null
foo.bar() // error{Maybe<Foo> does not have any bar method}

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

У Haskell це є з нуля ( Maybe), у C ++ ви можете скористатися, boost::optional<T>але ви все одно можете отримати невизначене поведінку ...

А яка альтернатива?

Необов'язкові типи та відповідність шаблонів. Оскільки я не знаю C #, ось фрагмент коду вигаданою мовою під назвою Scala # :-)

Customer.GetByLastName("Goodman")    // returns Option[Customer]
match
{
    case Some(customer) =>
    Console.WriteLine(customer.FirstName + " " + customer.LastName + " is awesome!");

    case None =>
    Console.WriteLine("There was no customer named Goodman.  How lame!");
}

Проблема з нулями полягає в тому, що мови, які дозволяють їм в значній мірі змушують вас програмувати оборонно проти цього. Для цього потрібно багато зусиль (набагато більше, ніж намагатися використовувати оборонні if-блоки)

1. об'єкти, від яких ви очікуєте, що вони не будуть нульовими, насправді ніколи не бувають нульовими, і
2. що ваші оборонні механізми дійсно ефективно справляються з усіма потенційними НПЗ.

Отже, дійсно, нулі в кінцевому рахунку є дорогою річчю.

Питання, якою мірою ваша мова програмування намагається довести правильність вашої програми ще до її запуску. Статично набраною мовою ви доказуєте, що у вас є правильні типи. Перемістившись за замовчуванням ненульових посилань (з необов'язковими нульовими посиланнями), ви можете усунути багато випадків, коли нуль передано, а цього не повинно бути. Питання полягає в тому, чи варто додаткове зусилля в обробці ненульових посилань корисним з точки зору коректності програми.

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

Наприклад, може виглядати ваш код

public void MakeCake(Egg egg, Flour flour, Milk milk)
{
    if (egg == null) { throw ... }
    if (flour == null) { throw ... }
    if (milk == null) { throw ... }

    egg.Crack();
    MixingBowl.Mix(egg, flour, milk);
    // etc
}

// inside Mixing bowl class
public void Mix(Egg egg, Flour flour, Milk milk)
{
    if (egg == null) { throw ... }
    if (flour == null) { throw ... }
    if (milk == null) { throw ... }

    //... etc
}

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

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

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

http://twistedoakstudios.com/blog/Post330_non-nullable-types-vs-c-fixing-the-billion-dollar-mistake

Цей список також вказаний як # 2, найбільш голосова функція для C # -> https://visualstudio.uservoice.com/forums/121579-visual-studio/category/30931-languages-c

Нуль - це зло. Однак відсутність нуля може бути більшим злом.

Проблема полягає в тому, що в реальному світі у вас часто виникає ситуація, коли у вас немає даних. Ваш приклад версії без нуля все ще може підірватися - або ви помилилися з логікою і забули перевірити Гудмена, або, можливо, Гудман одружився між вами, коли ви перевіряли, і коли ви її шукали. (Це допомагає в оцінці логіки, якщо ви вважаєте, що Моріарті переглядає кожний шматочок вашого коду і намагається відключити вас.)

Що робить пошук Гудмена, коли її там немає? Без нуля вам потрібно повернути якогось замовника за замовчуванням - і тепер ви продаєте речі до цього замовчування.

По суті, це зводиться до того, чи важливіше, щоб код працював незалежно від того, чи він працює правильно. Якщо неправильна поведінка є кращою перед будь-якою поведінкою, тоді ви не хочете нулів. (Для прикладу того, як це може бути правильним вибором, розглянемо перший запуск Ariane V. Помилка uncaught / 0 призвела до того, що ракета зробила важкий поворот, і самознищення вистрілило, коли вона розпалася через це. Значення він намагався обчислити, що насправді більше не виконував жодної мети, як тільки підсилювач прискорився - він вийшов би на орбіту, незважаючи на звичайне повернення сміття.)

Принаймні 99 разів із 100 я вирішив би використовувати нулі. Хоча я стрибну від радості на замітку до самої їх версії.

Оптимізуйте для найбільш поширеного випадку.

Потрібно весь час перевіряти наявність нуля - нудно - ви хочете мати можливість просто захопити об'єкт Замовника та працювати з ним.

У звичайному випадку це має спрацювати чудово - ви зробите пошук, дістаньте об'єкт і використовуєте його.

У винятковому випадку , коли ви (випадковим чином) шукаєте клієнта по імені, не знаючи, чи існує цей запис / об'єкт, вам знадобиться певна ознака того, що це не вдалося. У цій ситуації відповідь полягає у тому, щоб кинути виняток RecordNotFound (або дозволити провайдеру SQL нижче зробити це за вас).

Якщо у вас є ситуація, коли ви не знаєте, чи можете ви довіряти вхідним даним (параметру), можливо, тому, що вони були введені користувачем, ви також можете надати "TryGetCustomer (ім'я, клієнт)". візерунок. Перехресне посилання з int.Parse та int.TryParse.

Винятки не є рівними!

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

Уникаючи використання нульових об'єктів, ви приховуєте частину цих винятків. Я не кажу про приклад OP, коли він конвертує нульовий виняток вказівника в добре набраний виняток, це може бути насправді хорошою справою, оскільки збільшує читабельність. Однак коли ви приймаєте рішення типу Option, як вказував @Jonas, ви приховуєте винятки.

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

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

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

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

Використовуйте нульовий шаблон об'єкта. Іноді відсутнє значення є дійсним станом для вашої системи. Нульовий шаблон об'єкта є хорошим рішенням тут. Це дозволяє уникнути необхідності постійних явних перевірок, але все ж дозволяє представляти нульовий стан. Як це стверджують деякі люди, це не "обчислення помилки", оскільки в цьому випадку нульовий стан є дійсним семантичним станом. Незважаючи на це, ви не повинні використовувати цю модель, коли нульовий стан не є дійсним семантичним станом. Вам слід просто вийняти зміну поза рамками.

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

val customer = customerDb getByLastName "Goodman"
val awesomeMessage =
  customer map (c => s"${c.firstName} ${c.lastName} is awesome!")
val notFoundMessage = "There was no customer named Goodman.  How lame!"
println(awesomeMessage getOrElse notFoundMessage)

У другому рядку, де ми будуємо дивовижне повідомлення, ми не робимо чіткої перевірки, чи був знайдений клієнт, і краса в цьому нам не потрібна . Це не останній рядок, який може бути багато рядків пізніше, або навіть в іншому модулі, де ми явно стосуємося себе, що станеться, якщо Optionє None. Мало того, що якби ми забули це зробити, це не перевірило б тип. Вже тоді це робиться дуже природним чином, без явного ifтвердження.

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

Основна проблема NULL полягає в тому, що вона робить систему ненадійною. У 1980 році Тоні Хоаре в роботі, присвяченій нагороді Тюрінга, написав:

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

Мова ADA з цього часу сильно змінилася, однак такі проблеми все ще існують у Java, C # та багатьох інших популярних мовах.

Обов'язком розробника є створення контрактів між клієнтом та постачальником. Наприклад, в C #, як і в Java, ви можете використовувати Genericsдля мінімізації впливу Nullпосилань, створюючи лише для читання NullableClass<T>(два варіанти):

class NullableClass<T>
{
     public HasValue {get;}
     public T Value {get;}
}

а потім використовувати його як

NullableClass<Customer> customer = dbRepository.GetCustomer('Mr. Smith');
if(customer.HasValue){
  // one logic with customer.Value
}else{
  // another logic
} 

або використовувати два варіанти стилю за допомогою методів розширення C #:

customer.Do(
      // code with normal behaviour
      ,
      // what to do in case of null
) 

Різниця значна. Як клієнт методу, ви знаєте, чого очікувати. Команда може мати правило:

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

Команда може посилити цю ідею, використовуючи Design by Contract та статичну перевірку під час компіляції, наприклад, з попередньою умовою:

function SaveCustomer([NotNullAttribute]Customer customer){
     // there is no need to check whether customer is null 
     // it is a client problem, not this supplier
}

або для струни

function GetCustomer([NotNullAndNotEmptyAttribute]String customerName){
     // there is no need to check whether customerName is null or empty 
     // it is a client problem, not this supplier
}

Цей підхід може різко підвищити надійність програми та якість програмного забезпечення. «Дизайн за контрактом» - це справа логіки Хоара , яку Бертран Мейєр заповнив у своїй відомій книзі «Об’єктно-орієнтована побудова програмного забезпечення» та Ейфелевій мові в 1988 році, але вона не використовується неправомірно в сучасній розробці програмного забезпечення.

Немає.

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

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

По суті, основна ідея полягає в тому, що проблеми з посиланням на нульові покажчики повинні потрапляти під час компіляції замість часу виконання. Отже, якщо ви пишете функцію, яка займає якийсь об'єкт, і ви не хочете, щоб хтось називав її нульовими посиланнями, тоді система типу повинна дозволяти вам вказати цю вимогу, щоб компілятор міг її використовувати, щоб гарантувати, що виклик вашої функції ніколи не буде компілювати, якщо абонент не відповідає вашим вимогам. Це можна зробити багатьма способами, наприклад, прикрашаючи типи або використовуючи типи опцій (які також називаються змінними типами на деяких мовах), але очевидно, що це набагато більше роботи для дизайнерів-компіляторів.

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

У мене є одне просте заперечення проти null:

Це повністю порушує семантику вашого коду, вносячи неоднозначність .

Часто ви очікуєте, що результат буде певним. Це семантично звучить. Скажімо, ви попросили базу даних для користувача з певним id, ви очікуєте, що певна версія буде певного типу (= user). Але що робити, якщо користувача цього ідентифікатора немає? Одне (погане) рішення: додавання nullзначення. Тому результат неоднозначний : або він є, userабо є null. Але nullце не очікуваний тип. І ось тут починається кодовий запах .

Уникаючи null, ви робите свій код семантично зрозумілим.

Є завжди способи навколо null: рефакторінга колекціям, Null-objects, і optionalsт.д.

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

1. Майте місцями за замовчуванням нульовий вказівник, але не дозволяйте коду переглядати їх (або навіть визначати, що вони є нульовими), без збоїв. Можливо, надайте явний спосіб встановлення покажчика на нуль.
2. Зазначте розташування за замовчуванням на нульовий покажчик та збийте, якщо буде зроблена спроба прочитати його, але надайте засоби без збоїв для тестування, чи покажчик містить нуль. Надайте також експлікаційний засіб встановлення покажчика на нуль.
3. Зазначте розташування за замовчуванням на вказівник на якийсь конкретний екземпляр за замовчуванням, що постачається компілятором, зазначеного типу.
4. Зазначте розташування за замовчуванням на вказівник на якийсь конкретний екземпляр за замовчуванням, що постачається програмою, зазначеного типу.
5. Будь-який доступ з нульовим покажчиком (а не лише операції з перенаправлення) викликає деяку програмну програму для подання екземпляра.
6. Створіть мовну семантику таким чином, що колекції місць зберігання не існуватимуть, за винятком неприступного компілятора тимчасово, до тих пір, поки підпрограми ініціалізації не будуть запущені для всіх членів (щось на зразок конструктора масиву повинно бути поставлено або з екземпляром за замовчуванням, функція, яка повертає екземпляр або, можливо, пару функцій - одну для повернення екземпляра та ту, яка буде викликана в раніше побудованих екземплярах, якщо виняток виникає під час побудови масиву).

Останній вибір може мати певну привабливість, особливо, якщо мова включає в себе як зведені, так і нерегульовані типи (можна було б викликати спеціальні конструктори масивів для будь-яких типів, але потрібно лише викликати їх під час створення масивів ненульованих типів), але, мабуть, це було б нездійсненно впродовж часу, коли були винайдені нульові покажчики. З інших варіантів жоден не здається привабливішим, ніж дозволяти скопіювати нульові вказівники, але не перенаписати чи індексувати. Підхід №4 може бути зручним, як варіант, і повинен бути досить дешевим у здійсненні, але це, звичайно, не повинно бути єдиним варіантом. Вимагати, щоб покажчики повинні за замовчуванням вказувати на якийсь конкретний дійсний об'єкт, набагато гірше, ніж мати покажчики за замовчуванням на нульове значення, яке можна прочитати чи скопіювати, але не перенаписати чи індексувати.

Так, NULL - це жахливий дизайн , в об'єктно-орієнтованому світі. Коротше кажучи, використання NULL призводить до:

• спеціальна обробка помилок (замість винятків)
• неоднозначне смислове
• повільний, а не швидкий збій
• комп'ютерне мислення проти об’єктного мислення
• змінні та неповні предмети

Перегляньте цю публікацію в блозі для детального пояснення: http://www.yegor256.com/2014/05/13/why-null-is-bad.html