Почему "null" присутствует в C# и Java?

Я не могу говорить о вашей конкретной проблеме, но похоже, что проблема не в существовании null. Null существует в базах данных, вам нужно каким-то образом учесть это на уровне приложения. Я не думаю, что это единственная причина, по которой он существует в .net, заметьте. Но я думаю, это одна из причин.

Null - чрезвычайно мощная функция. Что делать, если у вас нет ценности? Это NULL!

Одна школа мысли - никогда не возвращать null, другая - всегда. Например, некоторые говорят, что вы должны вернуть действительный, но пустой объект.

Я предпочитаю null, поскольку для меня это более верное указание на то, что это на самом деле. Если я не могу получить объект со своего уровня сохраняемости, мне нужен null. Мне не нужно какое-то пустое значение. Но это я.

Это особенно удобно с примитивами. Например, если у меня есть true или false, но это используется в форме безопасности, где разрешение может быть Разрешено, Запрещено или не установлено. Ну, я хочу, чтобы это не было нулевым. Значит, я могу использовать bool?

Я мог бы рассказать гораздо больше, но я оставлю это здесь.

Null - важное требование любого объектно-ориентированного языка. Любая объектная переменная, которой не была назначена ссылка на объект, должна иметь значение NULL.

Нулевое значение - естественное следствие ссылочных типов. Если у вас есть ссылка, она должна ссылаться на какой-то объект - или быть нулевой. Если бы вы запретили обнуление, вам всегда нужно было бы убедиться, что каждая переменная была инициализирована каким-либо ненулевым выражением - и даже тогда у вас возникли бы проблемы, если бы переменные были прочитаны во время фазы инициализации.

Как бы вы предложили убрать понятие ничтожности?

«Нулевой» включен в язык, потому что у нас есть типы значений и ссылочные типы. Вероятно, это побочный эффект, но я думаю, он хороший. Это дает нам большую власть над тем, как эффективно управлять памятью.

Почему у нас null? ...

Типы значений хранятся в «стеке», их значение находится непосредственно в этой части памяти (т.е. int x = 5 означает, что ячейка памяти для этой переменной содержит «5»).

С другой стороны, ссылочные типы имеют "указатель" в стеке, указывающий на значение действительный в куче (т.е. строка x = "ello" означает, что блок памяти в стеке содержит только адрес, указывающий на фактическое значение в куче. ).

Нулевое значение просто означает, что наше значение в стеке не указывает на какое-либо фактическое значение в куче - это пустой указатель.

Надеюсь, я объяснил это достаточно хорошо.

Удаление null многого не решит. Вам понадобится ссылка по умолчанию для большинства переменных, установленных при инициализации. Вместо исключений с нулевой ссылкой вы получите неожиданное поведение, потому что переменная указывает на неправильные объекты. По крайней мере, нулевые ссылки быстро выходят из строя, а не вызывают неожиданное поведение.

Вы можете посмотреть на шаблон нулевого объекта, чтобы решить часть этой проблемы.

Андерс Хейлсберг, «отец C#», только что рассказал об этом в его интервью Computerworld:

For example, in the type system we do not have separation between value and reference types and nullability of types. This may sound a little wonky or a little technical, but in C# reference types can be null, such as strings, but value types cannot be null. It sure would be nice to have had non-nullable reference types, so you could declare that ‘this string can never be null, and I want you compiler to check that I can never hit a null pointer here’.

50% of the bugs that people run into today, coding with C# in our platform, and the same is true of Java for that matter, are probably null reference exceptions. If we had had a stronger type system that would allow you to say that ‘this parameter may never be null, and you compiler please check that at every call, by doing static analysis of the code’. Then we could have stamped out classes of bugs.

Сайрус Наджмабади, бывший инженер-разработчик программного обеспечения в команде C# (теперь работающей в Google), обсуждает эту тему в своем блоге: (1-й, 2-й, 3-й, 4-й). Кажется, что самым большим препятствием для принятия типов, не допускающих значения NULL, является то, что нотация нарушит привычки программистов и базу кода. Примерно 70% ссылок на программы C#, скорее всего, завершатся как не допускающие значения NULL.

Если вы действительно хотите иметь ссылочный тип, не допускающий значения NULL, в C#, вам следует попробовать использовать Спецификация # которое является расширением C#, которое позволяет использовать "!" как знак, не допускающий значения NULL.

static string AcceptNotNullObject(object! s)
{
    return s.ToString();
}

Нулевой в C# в основном является переносом из C++, в котором были указатели, которые ни на что не указывали в памяти (или, скорее, на адрес 0x00). В это интервью Андерс Хейлсберг говорит, что он хотел бы добавить в C# ссылочные типы, не допускающие значения NULL.

Однако Null также имеет законное место в системе типов, как что-то вроде нижний тип (где object - это тип Вверх). В lisp нижний тип - NIL, а в Scala - Nothing.

Можно было бы разработать C# без каких-либо нулей, но тогда вам нужно было бы найти приемлемое решение для тех применений, которые обычно используются для null, например unitialized-value, not-found, default-value, undefined-value и None<T>. Вероятно, программисты на C++ и Java, вероятно, не приняли бы такого решения, если бы им это все-таки удалось. По крайней мере, до тех пор, пока они не увидят, что программы на C# никогда не имеют исключений с нулевым указателем.

Если вы создаете объект с переменной экземпляра, являющейся ссылкой на какой-либо объект, какое значение вы бы предложили для этой переменной, прежде чем назначать ей какую-либо ссылку на объект?

Бывают ситуации, когда нулевой - хороший способ обозначить, что ссылка не была инициализирована. Это важно в некоторых сценариях.

Например:

MyResource resource;
try
{
  resource = new MyResource();
  //
  // Do some work
  //
}
finally
{
  if (resource != null)
    resource.Close();
}

В большинстве случаев это достигается с помощью оператора с использованием. Но узор по-прежнему широко используется.

Что касается вашего исключения NullReferenceException, причину таких ошибок часто легко уменьшить, реализовав стандарт кодирования, в котором все параметры проверяются на достоверность. В зависимости от характера проекта я считаю, что в большинстве случаев достаточно проверить параметры на открытых элементах. Если параметры находятся за пределами ожидаемого диапазона, выдается ArgumentException какого-либо типа или возвращается результат ошибки, в зависимости от используемого шаблона обработки ошибок.

Проверка параметров сама по себе не устраняет ошибки, но любые возникающие ошибки легче обнаружить и исправить на этапе тестирования.

В качестве примечания, Андерс Хейлсберг упомянул отсутствие принудительного применения ненулевого значения как одну из самых больших ошибок в спецификации C# 1.0, и что теперь включить ее «сложно».

Если вы все еще думаете, что статически принудительное ненулевое ссылочное значение имеет большое значение, вы можете проверить язык speC#. Это расширение C#, в котором ненулевые ссылки являются частью языка. Это гарантирует, что ссылке, помеченной как ненулевое, никогда не может быть присвоена пустая ссылка.

Null в том виде, в каком он доступен в C# / C++ / Java / Ruby, лучше всего рассматривать как причуду какого-то неясного прошлого (Algol), которое каким-то образом сохранилось до наших дней.

Вы можете использовать его двумя способами:

• Объявлять ссылки без их инициализации (плохо).
• Обозначить необязательность (ОК).

Как вы уже догадались, 1) это то, что вызывает у нас бесконечные проблемы в общих императивных языках и должно было быть запрещено давно, 2) это действительно существенная особенность.

Существуют языки, которые избегают 1), но не препятствуют 2).

Например, таким языком является OCaml.

Простая функция, возвращающая постоянно увеличивающееся целое число, начиная с 1:

let counter = ref 0;;
let next_counter_value () = (counter := !counter + 1; !counter);;

Что касается опциональности:

type distributed_computation_result = NotYetAvailable | Result of float;;
let print_result r = match r with
    | Result(f) -> Printf.printf "result is %f\n" f
    | NotYetAvailable -> Printf.printf "result not yet available\n";;

Если вы получаете исключение NullReferenceException, возможно, вы продолжаете ссылаться на объекты, которые больше не существуют. Это не проблема с "null", это проблема с вашим кодом, указывающим на несуществующие адреса.

Я удивлен, что никто не сказал в ответ о базах данных. В базах данных есть поля, допускающие значение NULL, и любой язык, который будет получать данные из БД, должен это обрабатывать. Это означает наличие нулевого значения.

Фактически, это настолько важно, что для базовых типов, таких как int, вы можете сделать их допускающими значение NULL!

Также рассмотрите возвращаемые значения из функций, что, если бы вы хотели, чтобы функция делила пару чисел, а знаменатель мог бы быть 0? Единственный «правильный» ответ в таком случае будет нулевым. (Я знаю, что в таком простом примере исключение, вероятно, было бы лучшим вариантом ... но могут быть ситуации, когда все значения верны, но действительные данные могут дать неверный или неисчислимый ответ. Не уверен, что в таком случаи...)

В одном из ответов упоминалось, что в базах данных есть нули. Это правда, но они сильно отличаются от нулей в C#.

В C# нули - это маркеры для ссылки, которая ни на что не ссылается.

В базах данных пустые значения - это маркеры для ячеек значений, которые не содержат значения. Под ячейками значений я обычно подразумеваю пересечение строки и столбца в таблице, но концепция ячеек значений может быть расширена за пределы таблиц.

На первый взгляд разница между ними кажется тривиальной. Но это не так.

After all, if there were no "null", I would have no bug, right?

Ответ - НЕТ. Проблема не в том, что C# допускает null, проблема в том, что у вас есть ошибки, которые проявляются с помощью NullReferenceException. Как уже было сказано, нули имеют цель в языке обозначать либо «пустой» ссылочный тип, либо не-значение (пусто / ничего / неизвестно).

Null не вызывает исключений NullPointerExceptions ...

Программисты вызывают исключения NullPointerExceptions.

Без нулей мы возвращаемся к использованию фактического произвольного значения, чтобы определить, что возвращаемое значение функции или метода было недопустимым. Вам все равно нужно проверять возвращаемое -1 (или что-то еще), удаление нулей не решит волшебным образом лени, а лишь слегка запутает ее.

Я предлагаю:

1. Ban Null
2. Расширить логические значения: True, False и FileNotFound

Обычно - NullReferenceException означает, что какому-то методу не понравилось то, что ему было передано, и он вернул пустую ссылку, которая позже использовалась без проверки ссылки перед использованием.

Этот метод мог бы показать более подробное исключение вместо возврата null, что соответствует режиму мышления быстро потерпеть неудачу.

Или метод может возвращать null для вашего удобства, чтобы вы могли написать если вместо пытаться и избежать «накладных расходов» исключения.

Помимо ВСЕХ уже упомянутых причин, NULL необходим, когда вам нужен заполнитель для еще не созданного объекта. Например. если у вас есть круговая ссылка между парой объектов, вам понадобится null, поскольку вы не можете создать оба экземпляра одновременно.

class A {
  B fieldb;
}

class B {
  A fielda;
}

A a = new A() // a.fieldb is null
B b = new B() { fielda = a } // b.fielda isnt
a.fieldb = b // now it isnt null anymore

Обновлено: вы можете вытащить язык, который работает без нулей, но это определенно не будет объектно-ориентированным языком. Например, пролог не имеет нулевых значений.

Вопрос можно интерпретировать как «Лучше иметь значение по умолчанию для каждого типа ссылки (например, String.Empty) или null?». В этом предположении я бы предпочел иметь нули, потому что;

• Я бы не хотел писать дефолт конструктор для каждого класса, который я пишу.
• Я бы не хотел лишнего память для таких значения по умолчанию.
• Проверка наличия ссылка нулевая, гораздо дешевле чем сравнение значений.
• Это очень возможно иметь больше ошибок, которые труднее обнаружить, вместо NullReferanceExceptions. Это хорошо иметь такое исключение что ясно указывает на то, что я делать (предполагать) что-то не так.

Как и многие вещи в объектно-ориентированном программировании, все восходит к АЛГОЛу. Тони Хоар назвал это своей «ошибкой на миллиард долларов». Во всяком случае, это преуменьшение.

Вот действительно интересный тезис о том, как сделать обнуление не значением по умолчанию в Java. Параллели с C# очевидны.

• Явное обнуление, хотя это бывает редко. Возможно, это можно рассматривать как форму защитного программирования.
• Используйте его (или структуру, допускающую значение NULL (T) для значений, не допускающих значения NULL) в качестве флага, чтобы указать отсутствующее поле при сопоставлении полей из одного источника данных (поток байтов, таблица базы данных) объекту. Создание логического флага для каждого возможного поля, допускающего значение NULL, может стать очень громоздким, и может оказаться невозможным использовать контрольные значения, такие как -1 или 0, когда все значения в диапазоне этого поля допустимы. Это особенно удобно, когда полей очень много.

Являются ли они случаями использования или злоупотребления - это субъективно, но я иногда их использую.

Если фреймворк позволяет создавать массив некоторого типа без указания, что следует делать с новыми элементами, этот тип должен иметь какое-то значение по умолчанию. Для типов, которые реализуют семантику изменяемых ссылок (*), в общем случае нет разумного значения по умолчанию. Я считаю слабым местом платформы .NET отсутствие возможности указать, что вызов невиртуальной функции должен подавлять любую проверку на null. Это позволит неизменным типам, таким как String, вести себя как типы значений, возвращая разумные значения для таких свойств, как Length.

(*) Обратите внимание, что в VB.NET и C# семантика изменяемых ссылок может быть реализована либо классом, либо типом структуры; Тип структуры будет реализовывать семантику изменяемых ссылок, действуя как прокси для обернутого экземпляра объекта класса, на который он содержит неизменяемую ссылку.

Также было бы полезно, если бы можно было указать, что класс должен иметь не допускающую обнуления семантику изменяемого типа значения (подразумевая, что - как минимум - создание экземпляра поля этого типа приведет к созданию нового экземпляра объекта с использованием конструктора по умолчанию, и что копирование поля этого типа приведет к созданию нового экземпляра путем копирования старого (рекурсивная обработка любых вложенных классов типов значений).

Однако неясно, какая именно поддержка должна быть встроена в структуру для этого. Если сама структура распознает различия между изменяемыми типами значений, изменяемыми ссылочными типами и неизменяемыми типами, это позволит классам, которые сами содержат ссылки на смесь изменяемых и неизменяемых типов из внешних классов, эффективно избегать создания ненужных копий глубоко неизменяемых объектов.

Извините за то, что ответил с опозданием на четыре года, я удивлен, что ни один из ответов до сих пор не ответил на исходный вопрос таким образом:

Такие языки, как C# и Java, такие как C и другие предшествующие им языки, есть null, чтобы программист мог писать быстрый, оптимизированный код эффективно использовать указатели.

• Низкоуровневый вид

Сначала немного истории. Причина, по которой был изобретен null, - это эффективность. При низкоуровневом программировании на ассемблере нет абстракции, у вас есть значения в регистрах, и вы хотите максимально использовать их. Определение нуля как значения недействительный указатель - отличная стратегия для представления либо предмет, либо ничего.

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

• Общий вид.

Семантически null не является необходимым для языков программирования. Например, в классических функциональных языках, таких как Haskell или в семействе ML, нет null, а есть типы с именем Maybe или Option. Они представляют собой более высокоуровневую концепцию необязательное значение, никоим образом не заботясь о том, как будет выглядеть сгенерированный код сборки (это будет работа компилятора).

И это тоже очень полезно, потому что позволяет компилятору использовать поймать больше ошибок, а это означает меньше исключений NullReferenceExceptions.

• Объединяя их

В отличие от этих языков программирования очень высокого уровня, C# и Java допускают возможное значение null для каждый ссылочный тип (это другое название для тип, который в конечном итоге будет реализован с использованием указателей).

Это может показаться плохим, но что хорошо в этом, так это то, что программист может использовать знания о том, как это работает под капотом, для создания более эффективного кода (даже если в языке есть сборка мусора).

Это причина, по которой null все еще существует в языках сегодня: компромисс между потребностью в общей концепции необязательного значения и вездесущей потребностью в эффективности.

Функция, которая не может работать без нуля, - это возможность представить «отсутствие объекта».

Отсутствие объекта - важное понятие. В объектно-ориентированном программировании он нужен нам для представления ассоциации между объектами, которая является необязательной: объект A может быть присоединен к объекту B, или A может не иметь объекта B. Без нуля мы все равно могли бы эмулировать это: например, мы могли бы использовать список объектов, чтобы связать B с A. Этот список может содержать один элемент (один B) или быть пустым. Это несколько неудобно и на самом деле ничего не решает. Код, который предполагает, что существует B, например aobj.blist.first().method(), взорвется аналогично исключению с нулевой ссылкой: (если blist пуст, каково поведение blist.first()?)

Говоря о списках, null позволяет завершить связанный список. ListNode может содержать ссылку на другой ListNode, которая может иметь значение NULL. То же самое можно сказать и о других структурах динамического набора, таких как деревья. Null позволяет вам иметь обычное двоичное дерево, конечные узлы которого помечены имеющими дочерние ссылки, которые имеют значение NULL.

Списки и деревья могут быть построены без нуля, но они должны быть круговыми или бесконечными / ленивыми. Это, вероятно, будет расценено как неприемлемое ограничение для большинства программистов, которые предпочли бы иметь возможность выбора при разработке структур данных.

Проблемы, связанные с нулевыми ссылками, такими как пустые ссылки, случайно возникающие из-за ошибок и вызывающие исключения, частично являются следствием системы статических типов, которая вводит нулевое значение в каждый тип: есть пустая строка, нулевое целое число, нулевой виджет, ...

В динамически типизированном языке может быть один нулевой объект, который имеет свой собственный тип. В результате у вас есть все репрезентативные преимущества null плюс большая безопасность. Например, если вы пишете метод, который принимает параметр String, то вам гарантируется, что параметр будет строковым объектом, а не null. В классе String нет нулевой ссылки: то, что известно как String, не может быть нулевым объектом. Ссылки не имеют типа на динамическом языке. Место хранения, такое как член класса или параметр функции, содержит значение, которое может быть ссылкой на объект. Этот объект имеет тип, а не ссылку.

Таким образом, эти языки предоставляют чистую, более или менее математически чистую модель «нуля», а затем статические языки превращают ее в своего рода монстра Франкенштейна.