NullReferenceException при условной нулевой проверке?

Я пытаюсь исправить ошибку, которую не могу воспроизвести (ура!). У меня есть трассировка стека, которая была скопирована пользователем, который изначально обнаружил проблему, и она показывает код, генерирующий исключение нулевой ссылки (которое не обрабатывается) в строке, которая проверяет объект на нуль ... например:

private void someFunction()
{
    radioButton1.CheckedChanged -= checkedChangedEventHandler
    radioButton2.CheckedChanged -= checkedChangedEventHandler

    if (someObject != null)  // throws NullReferenceException...allegedly
    {
         if (someObject.Property == something)
         {
            // set properties on some UI components
         }
    }
}

Какие условия могли это вызвать?

ОБНОВЛЕНИЕ

Добавил еще код. Метод SomeFunction вызывается обработчиками событий checkedChanged.

ОБНОВЛЕНИЕ 2

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

Вот поток, объясняющий трассировку стека с неправильными номерами строк:

Неверный номер строки при трассировке стека


.net c# nullreferenceexception
person alexD    schedule 01.07.2011    source источник
comment
Отметьте это как norepro в своем баг-трекере и двигайтесь дальше! знак равно   -  person Yuck    schedule 01.07.2011
comment
Вы можете показать нам трассировку стека?   -  person Ahmad Mageed    schedule 01.07.2011
comment
Есть ли еще код, который мы могли бы увидеть?   -  person SirPentor    schedule 01.07.2011
comment
Насколько вы уверены, что текущая версия кода соответствует трассировке стека?   -  person Anthony Pegram    schedule 01.07.2011
comment
Иногда может показаться, что исключение было выброшено в строке, следующей за той, где оно было на самом деле. Вы проверили строку выше?   -  person Martin Törnwall    schedule 01.07.2011
comment
вы можете вставить сюда трассировку стека?   -  person Nitesh    schedule 01.07.2011
comment
@Ahmad & tech p - К сожалению, я не могу ... код находится в другой сети, не подключенной к Интернету. Я проверю его для получения более подробной информации, которая может быть полезна.   -  person alexD    schedule 01.07.2011
comment
@Tobias: Да, я скоро отредактирую его, чтобы показать, что было до и после. @ Martin - да, только две строки над ним в функции удаляют обработчики событий из двух переключателей.   -  person alexD    schedule 01.07.2011

Ответы (3)


arrow_upward
4
arrow_downward

Двумя наиболее вероятными кандидатами являются:

  1. Перегруженный оператор! = Вызывает хаос (хотя можно подумать, что трассировка стека показывает это).
  2. Трассировка стека неверна, и вам нужно больше информации, чтобы продолжить.

Я думаю, что 2 более вероятно.

person dlev    schedule 01.07.2011
comment
Похоже, это должен быть №2. Я опубликую обновление, если действительно найду причину. - person alexD; 01.07.2011

arrow_upward
8
arrow_downward

someObject перегружен != оператор?

http://msdn.microsoft.com/en-us/library/8edha89s(v=vs.71).aspx

person Daniel Mošmondor    schedule 01.07.2011
comment
... и проделали ужасную работу! - person Anthony Pegram; 01.07.2011
comment
Нет ... это не перегружает оператор! =. Объект реализует несколько интерфейсов, ни один из которых ничего не перегружает. - person alexD; 01.07.2011

arrow_upward
0
arrow_downward

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

Неверный номер строки при трассировке стека

номера строк трассировки стека неверны при отладке = false и compilerOptions = / debug: pdbonly

person alexD    schedule 01.07.2011