Определение целевого объекта при возникновении исключения NullReferenceException

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

вы можете проверить свойства Message и InnerException

http://msdn.microsoft.com/en-us/library/system.exception.innerexception.aspx

Ну, вы не можете действительно идентифицировать объект, поскольку он не существует и, следовательно, исключение, которое вы получаете.

Строка # и файл обычно все, что вам нужно, чтобы найти виновника. Если вы являетесь тем, кто генерирует исключение, рассмотрите возможность использования ArgumentNullException, если это необходимо, или проверки на нули и выброса NullReferenceException, которые имеют более подробную информацию о пустом поле.

Отредактируйте @ ваше редактирование :)

AFAIK, вам нужно будет изучить строку трассировки стека, чтобы получить эту строку # и файл. Лучше всего было бы получить самое внутреннее исключение, а затем посмотреть на первую строку его трассировки стека. Если вы хотите иметь возможность программно проанализировать эту информацию, чтобы выяснить, какое поле вызвало значение null, и сделать что-нибудь с именем этого поля, я боюсь, вам не повезет.

@W. Крейг Трейдер

Хорошая точка зрения. Для нулевого значения, которое передается в метод, должен быть выдан ArgumentNullException. Для переменной-члена, которая еще не была инициализирована, вероятно, было бы хорошо использовать что-то вроде InvalidStateException. К сожалению, я не могу найти такого исключения в MSDN. Свернуть свой собственный?

Если вы перехватываете исключения для удобных пользовательских сообщений или ведения журнала, вы, вероятно, захотите, чтобы отладчик останавливался на исключении во время отладки. Перейдите в Debug / Exceptions и проверьте типы исключений, при которых вы хотите, чтобы отладчик прекратил работу, в вашем случае System.NullReferenceException.

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

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

Лучшее решение такого рода проблем - Дизайн по контракту, либо через встроенные языковые конструкции, либо через библиотеку. DbC предлагает предварительно проверить все входящие аргументы для метода на предмет данных, выходящих за пределы допустимого диапазона (например, Null), и выдавать исключения, поскольку этот метод не будет работать с неверными данными.

[Изменить в соответствии с редактированием вопроса:]

Я думаю, что описание NRE вводит вас в заблуждение. Проблема, с которой сталкивается среда CLR, заключается в том, что ее попросили разыменовать ссылку на объект, когда ссылка на объект имеет значение Null. Возьмем этот пример программы:

public class NullPointerExample {
  public static void Main()
  {
    Object foo;
    System.Console.WriteLine( foo.ToString() );
  }
}

Когда вы запустите это, он выбросит NRE в строке 5, когда он попытается оценить метод ToString () для foo. Нет объектов для отладки, только ссылка на неинициализированный объект (foo). Есть класс и метод, но нет объекта.

Re: отвечать Криса Марасти-Георга:

Вы никогда не должны сами выбрасывать NRE - это системное исключение с определенным значением: CLR (или JVM) попыталась оценить ссылку на объект, которая не была инициализирована. Если вы предварительно проверяете ссылку на объект, то либо выдает какое-то исключение недопустимого аргумента или исключение для конкретного приложения, но не NRE, потому что вы только запутаете следующего программиста, который должен поддерживать ваше приложение.

Для справки аналогичная ветка: Должен ли я ловить исключения только для их регистрации?

Важным моментом является то, что вы хотите эффективно зафиксировать исключение. По моему опыту, цель состоит в том, чтобы убедиться, что программист проверяет в коде пустые ссылки, однако мы знаем, что на самом деле некоторые из них мы упускаем. Код пользовательского интерфейса должен иметь некоторый уровень обработки исключений. Мне понравился мой ответ на этот вопрос: Мой ответ. Что еще более важно, комментарий 1800 информации, который указал, что вы просто бросаете, а не бросаете ex, чтобы захватить всю трассировку стека, и именно так вы в конечном итоге отлаживаете эти проблемы.

Как указывалось в нескольких ответах, сообщите Visual Studio о прерывании Throw для NullReferenceException.

Как сказать VS прекращать работу при генерировании необработанных исключений

• Меню отладки | Исключения (или Ctrl + Alt + E)
• Детализация исключений среды CLR
• Разберитесь в системе
• Найдите System.NullRefernceException и установите флажок «Прервать» всякий раз, когда возникает это исключение, вместо того, чтобы разрешать ему переходить к любым имеющимся блокам Catch.

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

Эта возможность полезна для всех видов исключений, включая настраиваемые (можно добавить полное имя типа, и VS сопоставит его во время отладки)

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

Еще одна хитрость, которая может пригодиться (но только в некоторых языках), - это использование ключевого слова When (или аналогичного) ... В VB это выглядит как

Try
  ' // Do some work           '
Catch ex As Exception When CallMethodToInspectException(ex)

End Try

Уловка здесь в том, что выражение When оценивается как перед тем, как стек вызовов будет размотан в блок Catch. Поэтому, если вы используете отладчик, вы можете установить точку останова для этого выражения, и если вы посмотрите на окно стека вызовов (Debug | Windows | Callstack), вы можете увидеть и перейти к строке, которая вызвала исключение.

(Вы можете выбрать возврат false из CallMethodToInspectException, поэтому блок Catch будет проигнорирован, а среда выполнения продолжит поиск в стеке соответствующего блока Catch, что может позволить вести журнал, который не влияет на поведение, и с меньшими накладными расходами чем поймать и перебросить)

Если вас просто интересовало неинтерактивное ведение журнала, то при условии, что у вас есть сборка отладки (или, в некоторой степени, если вы решаете проблемы оптимизации, сборка выпуска с PDB), вы могли бы получить большую часть информации, необходимой для отслеживания ошибка из Exception ToString с включенной трассировкой стека с номером строки.

Если, однако, номера строки было недостаточно, вы также можете получить номер столбца (в значительной степени, конкретное локальное или нулевое выражение), извлекая StackTrace для исключения (используя либо описанный выше метод, либо просто в блоке catch. сам):

int colNumber = new System.Diagnostics.StackTrace(ex, true).GetFrame(0).GetFileColumnNumber();

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

Что касается настройки Visual Studio для перехвата исключения (как предлагается здесь), НЕ ЗАБУДЬТЕ удалить этот параметр после устранения проблемы. Я только что потратил полчаса, пытаясь понять, почему мое приложение зависло глубоко в какой-то части System.Windows.Forms ....