Получение имени переменной для NullReferenceException

Трассировки стека для NullReferenceException очень неинформативны, они просто включают имя метода и стек вызовов. Любая переменная в методе может быть нулевой, и ее сложно отлаживать, если ошибка не воспроизводится на машине разработчика.

Знаете ли вы способ получить больше информации об этой ошибке, возможно, получить имя переменной? Или у вас есть лучшие способы отладки?


debugging .net c# vb.net nullreferenceexception
person Elmo    schedule 23.12.2015    source источник
comment
Вы не можете получить имя переменной. Вы можете определить строку, в которой произошло исключение.   -  person Alex    schedule 23.12.2015
comment
@Alex Да, но в производстве требуется распространение файла .pdb. И это также предотвращает использование обфускаторов.   -  person Elmo    schedule 23.12.2015
comment
@Элмо, тогда удачи. Если вы используете обфускаторы, трассировка стека будет мусором.   -  person Aaron Carlson    schedule 23.12.2015
comment
@AaronCarlson Мой обфускатор позволяет мне превратить трассировку стека обратно в настоящие имена. Он не изменяет структуры программы, просто переименовывает все.   -  person Elmo    schedule 23.12.2015
comment
В зависимости от того, какой обфускатор вы используете, и если вы сохраняли PDB-файлы, сгенерированные из обфускатора, вы должны иметь возможность удаленно отлаживать код в действии.   -  person Aaron Carlson    schedule 23.12.2015
comment
msdn.microsoft.com/en-us/library /dd264808(v=vs.110).aspx ... вы всегда можете просто работать над предотвращением исключений нулевой ссылки.   -  person Matthew Whited    schedule 23.12.2015

Ответы (1)


arrow_upward
13
arrow_downward

Отследить это имя не всегда возможно (это может быть выражение).
А там, где это возможно, это повлечет за собой неприемлемые накладные расходы. Учтите, что среде выполнения пришлось бы отслеживать почти все ссылочные переменные, что было бы дорого и запрещало все виды оптимизации.

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

Простое решение состоит в том, чтобы встроить более согласованную проверку null в свой собственный код:

void Foo(Bar b)
{
   if (b == null) throw new ArgumentNullException(nameof(b));

   ...
}
person Henk Holterman    schedule 23.12.2015
comment
Особенно полезно, если вы включаете Debug.AssertNonNull (или что-то еще) только для проверки работоспособности при отладке позже. - person D. Ben Knoble; 23.12.2015
comment
в чем проблема накладных расходов в состоянии отладки? - person ahmadali shafiee; 07.01.2018
comment
Как добавление явной нулевой проверки и вызова nameof приводит к огромным накладным расходам? Вы говорите об оптимизации размера? Я бы предпочел контролировать этот выбор, если бы это был просто флаг компиляции. Это большая проблема с этими управляемыми платформами, где Microsoft решает, что для нас важно. Нам пришлось изо всех сил бороться за контроль над сбором кучи больших объектов. Нам было запрещено что-либо с этим делать, потому что Microsoft в своей бесконечной мудрости считала эту функцию ненужной в течение ГОДОВ. Не достаточно хорош. У меня есть место. Я хочу вариант. - person Shiv; 15.04.2019
comment
В качестве дополнительного примечания, если вы используете JetBrains.Annotations и ReSharper, есть (необязательно) сочетание клавиш на ! а также ? чтобы добавить атрибут NotNull и CanBeNull (соответственно) и повторно нажать ! на параметр с атрибутом notnull автоматически добавляется эта самая нулевая проверка, поэтому вам не нужно писать ее самостоятельно. - person jeromej; 17.07.2020