Bool wrong evaluated in If statement

Question

Just for curiosity

I have this problem on my code.

e is evaluated as false, (and I know that is getting false by seeing the data in the db) but the if statement doesn't care that, and assumes that is true, and is trying to throwing the exception.

Any ideas why?

edit:

• There is no ; at the end of line 16.

• The value false is correct, I have checked the database and is correct that is getting false, that was the expected

• the thing not expected is to get the exception
• Yes, with {} works fine. BUT I WANT TO KNOW why in this way is not working.
• Yes, clean, build, rebuild, everything, and getting the same
• No, I don't change the code while debugging. My solution is under x64, I'm not able to do the change

Answer 1

I saw a very similar question on SO recently but I cannot find it. While I'm off looking, here is what I remember from it, in case it helps ease your mind:

The symptoms were:

• Stepping through code via the debugger was stopping on a line that should not be executed
• The line of code is not actually executed when run outside of a debugger
• Adding curly braces around the offending line of code fixes the problem.

The reason has to do with the extra op codes that are emitted in Debug-enabled releases, to support step-through debugging. The actual IL code emitted for such releases includes extra "no-op" IL commands that do nothing except exist, and are used when stepping through code to break execution just before and/or after the "real" operations have run.

In this case, the IDE is just getting confused about which line of code is the "current" one based on the IL code it's trying to step through. The extra op code is there, as it should be, but the debugger IDE is incorrectly associating it with the previous line of code. The yellow highlight is in the wrong place.

I don't remember the exact conditions that make this happen (the answer to the original question actually dug into the IL to explain it, hopefully someone else can find that question!). Adding the braces causes the compiler to emit no-op op codes specifically to represent the braces, which is why the problem vanishes.

Answer 2

By chance - is there another variable somewhere defined named 'e' at a different scope, causing the compiler to get confused as to which value to use? Try changing 'e' to some other name.