предотвращение исключений нулевой ссылки

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

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

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

Использование Null Object Patterns является ключевым моментом.

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

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

Нет.

Вернее, нет ничего особенного в том, чтобы попытаться "предотвратить" NRE на C#. По большей части NRE - это просто какая-то логическая ошибка. Вы можете отгородиться от них на границах интерфейса, проверяя параметры и имея много кода типа

void Foo(Something x) {
    if (x==null)
        throw new ArgumentNullException("x");
    ...
}

повсюду (большая часть .Net Framework делает это), так что когда вы делаете ошибку, вы получаете немного более информативную диагностику (трасса стека, однако, еще более ценна, и NRE обеспечивает это тоже). Но вы все равно получаете исключение.

(Исключение: Такие исключения - NullReferenceException, ArgumentNullException, ArgumentException, ... - как правило, не должны попадаться программе, а просто означают "разработчик этого кода, есть ошибка, пожалуйста, исправьте ее". Я называю их исключениями 'время разработки'; они контрастируют с истинными исключениями 'время выполнения', которые происходят в результате окружения времени выполнения (например, FileNotFound) и предназначены для того, чтобы потенциально быть пойманными и обработанными программой. )

Но в конце концов, нужно просто правильно это закодировать.

В идеале большинство NRE никогда бы не случилось, так как для многих типов/переменных 'null' является бессмысленным значением, а в идеале статическая система типов запретила бы 'null' в качестве значения для этих конкретных типов/переменных. Тогда компилятор не позволил бы ввести этот тип случайной ошибки (исключая определенные классы ошибок, которые лучше всего подходят компиляторам и системам типов). В этом случае определенные языки и системы типов преуспевают.

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

В дополнение к вышесказанному ("Нулевые объекты", "Пустые коллекции"), существуют некоторые общие техники, а именно: Приобретение ресурсов - инициализация (RAII) с С++ и проектирование по контракту с компанией "Эйфель". Они сводятся к:

1. Инициализировать переменные с действительными значениями.
2. Если переменная может быть нулевой, то либо проверьте ее на наличие нуля и рассмотрите как особый случай, либо ожидайте исключение с нулевой ссылкой (и разберитесь с этим). Утверждения могут быть использованы для проверки на нарушение договора при разработке.

Я видел много кода, который выглядит так:

if ((value != null) && (value.getProperty() != null) && ... && (....). doSomethingUseful())

Большую часть времени это совершенно ненужно и большинство тестов можно убрать более строгой инициализацией и более жесткими определениями контрактов.

Если это проблема в вашей кодовой базе, то в каждом случае необходимо понимать, что представляет собой ноль:

1. Если ноль представляет пустую коллекцию, то используйте пустую коллекцию.
2. Если ноль представляет собой исключительный случай, бросьте Исключение.
3. Если ноль представляет случайно неинициализированную ценность, явно инициализируйте его.
4. Если ноль представляет собой законную ценность, протестируйте его - или даже лучше используйте NullObject, который выполняет нулевую операцию

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

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

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

List<Client> GetAllClients()
{
    List<Client> returnList = new List<Client>;
    /* insert code to go to data base and get some data reader named rdr */
   for (rdr.Read()
   {
      /* code to build Client objects and add to list */
   }

   return returnList;
}

Хорошо, это может выглядеть нормально, но в зависимости от ваших бизнес-правил, это может быть проблемой. Конечно, вы никогда не бросите нулевую ссылку, но, может быть, ваша таблица User никогда не должна быть пустой? Вы хотите, чтобы ваше приложение вращалось на месте, генерируя вызовы поддержки от пользователей, говорящих "это просто пустой экран", или вы хотите поднять исключение, которое может где-нибудь войти в журнал и быстро поднять тревогу? Не забудьте проверить, что вы делаете, а также "обработка" исключений. Это одна из причин, по которой некоторые не любят убирать нули из наших языков... это облегчает поиск ошибок, даже если это может привести к появлению новых.

Помните: Обращайтесь с исключениями, не скрывайте их.

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

Например

public MyClass
{
   private ISomeDependency m_dependencyThatWillBeUsedMuchLater 

   // passing a null ref here will cause 
   // an exception with a meaningful stack trace    
   public MyClass(ISomeDependency dependency)
   {
      if(dependency == null) throw new ArgumentNullException("dependency");

      m_dependencyThatWillBeUsedMuchLater = dependency;
   }

   // Used later by some other code, resulting in a NullRef
   public ISomeDependency Dep { get; private set; }
}

В приведенном выше коде, если вы передадите нулевое ref, то сразу же обнаружите, что код вызова использует тип некорректно. Если не было проверки нулевой ссылки, то ошибка может быть затушевана самыми разными способами.

Вы заметите, что библиотеки .NET-фреймворка почти всегда терпят неудачу раньше и часто, если вы предоставляете нулевые ссылки в тех случаях, когда это не корректно. Так как брошенное исключение явно говорит "ты облажался!" и объясняет почему, это делает обнаружение и исправление дефектного кода тривиальной задачей.

Я слышал жалобы от некоторых разработчиков, которые говорили, что эта практика слишком многословна и избыточна, так как NullReferenceException - это все, что вам нужно, но на практике я нахожу, что это имеет большое значение. Особенно, если стек вызовов глубокий и/или параметр хранится и его использование откладывается на более поздний срок (возможно, на другом потоке или скрыто каким-то другим образом).

Что бы вы предпочли, ArgumentNullException на входном методе, или непонятную ошибку в его кишках? Чем дальше от источника ошибки, тем труднее ее отследить.

Одна из наиболее распространенных ошибок нулевой ссылки, которую я видел, связана со строками. Будет проверка:

if(stringValue == "") {}

Но на самом деле строка нулевая. Так и должно быть:

if(string.IsNullOrEmpty(stringValue){}

Также, можно быть чересчур осторожным и проверять, что объект не является нулевым, прежде чем пытаться получить доступ к членам/методам этого объекта.

Соответствующее использование структурированной обработки исключений поможет избежать подобных ошибок.

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

Один из способов - использовать объекты Null Value Objects (также известные как Null Object Pattern) там, где это возможно. Здесь подробнее