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

Question

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

5

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

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

Elmo 23 дек. 2015, в 20:27

Источник

1

Вы не можете получить имя переменной. Вы можете определить строку, где произошло исключение.
Alex 23 дек. 2015, в 19:30
0

@Alex Алекс Да, но в производстве требуется распространение файла .pdb. И это также предотвращает использование обфускаторов.
Elmo 23 дек. 2015, в 19:31
4

@Elmo Elmo Тогда удачи. Если вы используете обфускаторы, трассировка стека будет мусором.
Aaron Carlson 23 дек. 2015, в 19:32
0

@AaronCarlson Мой обфускатор позволяет мне превратить трассировку стека в настоящие имена. Он не изменяет структуры программы, просто переименовывает все.
Elmo 23 дек. 2015, в 19:37
0

В зависимости от того, какой обфускатор вы используете, и если вы сохраняете файлы PDB, сгенерированные из обфускатора, вы сможете удаленно отлаживать код в действии.
Aaron Carlson 23 дек. 2015, в 19:37
0

msdn.microsoft.com/en-us/library/dd264808(v=vs.110).aspx ... вы всегда можете просто работать, чтобы предотвратить исключения nullreference.
Matthew Whited 23 дек. 2015, в 19:44

Показать ещё 4 комментария

Теги:

c#

.net

debugging

vb.net

nullreferenceexception

1 ответ

Ещё вопросы

Вы не можете получить имя переменной. Вы можете определить строку, где произошло исключение.
@Alex Алекс Да, но в производстве требуется распространение файла .pdb. И это также предотвращает использование обфускаторов.
@Elmo Elmo Тогда удачи. Если вы используете обфускаторы, трассировка стека будет мусором.
@AaronCarlson Мой обфускатор позволяет мне превратить трассировку стека в настоящие имена. Он не изменяет структуры программы, просто переименовывает все.
В зависимости от того, какой обфускатор вы используете, и если вы сохраняете файлы PDB, сгенерированные из обфускатора, вы сможете удаленно отлаживать код в действии.
msdn.microsoft.com/en-us/library/dd264808(v=vs.110).aspx ... вы всегда можете просто работать, чтобы предотвратить исключения nullreference.

Henk Holterman · Accepted Answer · 2015-12-23T21-05-00.000Z

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

Также см. мой ответ на Осмотрите управляемый стек и сообщение в блоге, на которое он ссылается.

Простым решением является построение более согласованной нулевой проверки в вашем собственном коде:

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

   ...
}

Это особенно полезно, если вы включаете Debug.AssertNonNull (или как он должен быть) только для проверки работоспособности при дальнейшей отладке.
В чем проблема издержек в состоянии отладки?
Как добавление явной нулевой проверки и nameof вызывает огромные накладные расходы? Вы говорите об оптимизации размера? Я бы предпочел контролировать этот выбор, если бы это был просто флаг компиляции. Это большая проблема с этими управляемыми платформами, где Microsoft решает, что для нас важно. Нам пришлось бороться изо всех сил за контроль над сбором кучи больших объектов. Нам было запрещено что-либо делать по этому поводу, потому что Microsoft в своей бесконечной мудрости считала эту «особенность» ненужной для ГОДОВ. Не достаточно хорош. У меня есть место. Я хочу вариант.