I'm trying to fix a bug that I cannot reproduce (yipeee!). I have the stack trace that was copied by the user that originally discovered the issue, and it shows the code throwing a null reference exception (which is unhandled) on a line that is checking the object for null..like this:
private void someFunction()
{
radioButton1.CheckedChanged -= checkedChangedEventHandler
radioButton2.Che开发者_Python百科ckedChanged -= checkedChangedEventHandler
if (someObject != null) // throws NullReferenceException...allegedly
{
if (someObject.Property == something)
{
// set properties on some UI components
}
}
}
What kind of conditions could cause this?
UPDATE
Added some more code. SomeFunction method gets called by the checkedChanged event handlers.
UPDATE 2
The stack trace must be wrong as several of you have suggested. There are no operator overloads, and the method only references four objects that are not UI components (labels and radio buttons), and all of those objects are assigned only once on initialization, and are referenced multiple times before ever getting to this code so any null references would have been caught way before this. I'll have to look more closely at the calling event handler function.
Here is a thread explaining stack traces with wrong line numbers:
Wrong line number on stack trace
someObject
has overloaded !=
operator?
http://msdn.microsoft.com/en-us/library/8edha89s(v=vs.71).aspx
The two most likely candidates are:
- An overloaded != operator is causing havoc (though you'd think the stack trace show that.)
- The stack trace is wrong, and you need more information to go forward.
I think 2 is more likely.
I just wanted to post this in here for anyone who stumbles across this thread. dlev gets the correct answer for suggesting it, but I thought it was still relevant to post as an answer:
Wrong line number on stack trace
stack trace line numbers are wrong with debug=false and compilerOptions="/debug:pdbonly"
精彩评论