views:

181

answers:

6

This behavior is so bizarre that I don't even know how best to ask the question.

Given the following C# code snippet:

public class Foo {
  private bool _value = true;

  // ...

  protected void Method()
  { 
    _value = true;
    if(!_value) {
      throw new Exception("What the...?!?!");
    }
  }
}

Attaching the Visual Studio debugger to an application executing a version of this code and stepping through the execution of Method() (using step into or step over), the if block is evaluated and the exception is thrown. Setting a watch on the _value variable, I can see that the value of _value is false at the beginning of the method and does not change as I step over/into the assignment statement. More interestingly, the exception is not thrown if I Continue execution (F5), though things still aren't working correctly.

I came across this when trying to figure out why NUnit test cases were working when run using ReSharper from within visual studio, but fail when run within the the NUnit GUI. I attached the debugger to the NUnit GUI, set some breakpoints on the tests that were unexpectedly failing, found places where variables weren't being set properly which should be set based on the above-mentioned _value variable which is somewhat of a flag indicating whether stuff is dirty or not), and thus noticed the strange behavior where _value wasn't changing (the exception throwing thing was added later and verifies I was using the right compiled assemblies!).

So, how about it? What could possibly explain the above-mentioned behavior?

A: 

I once had a similar scenario at work. There was a value that was most definitely false, and same thing like you, I had an if(value){...} and the if block got executed. After much hair pulling, it turned out to be a version-ing issue. To this day I don't fully understand what happened, but after removing the reference from my app to that assembly, taking it out of the gac, rebuilding it, re gac-ing it and then re-adding the reference back to my project, it worked as expected. I don't know if that's possible in your scenario, but give it a shot.

BFree
+1  A: 

Another thread might affect the value of the field in a race condition.

Mehrdad Afshari
A: 

Only explanations I can think of is that another thread is modifying the value. How do you invoke Method()?

Anthony Brien
+3  A: 

Since the exception isn't actually thrown in some scenario's I think this is a case of the debugger looking at the wrong source or wrong version.

Henk Holterman
Although I haven't confirmed it and don't wish to spend the time to do so, I believe the problem here iss that VS likes to copy referenced DLLs around for subprojects, but doesn't necessarily re-copy when it needs to. So, yes, likely a case where the debugger was using the wrong versions. Thanks!
iammichael
+3  A: 

Look if any property getters changes _value. The debugger will evaluate properties and thus your value may get changed.

chris
+1  A: 

Try rebuilding your solution (in Visual Studio menu choose: Build -> Rebuild Solution), and then try again.

John Rasch