Visual Studio Debug is Breaking inside if statement with false check

So I'm trying to get the debugger the pause after I'm moving with some speed. But for some reason it's pausing immediately even though the h value is zero. It never goes into the if statement and yet it's pausing anyways? This seems to happen everywhere. I am baffle and more than a little frustrated. Someone please tell me there's some setting with debugging that stops on breakpoints even if it never visits the line in question, that I can disable.

 

Never seen that before. Curious why you're calling Debug.Break() as well as having a break-point there though.

 

I'm guessing this is an artifact of misplaced line number information for the debugger. You're putting a bkpt on one line but the actual mapping to IL instructions is wrong. That's just a guess however.

Try doing a Debug.Log( "h = " + h); right before the Debug.Break() and it should print a nonzero value to the console.

 

This is pretty common with unity and breakpoints unfortunately.

I've seen it more times than I can count. Mostly I'll encounter it when trying to step in / out of functions.

Your Debug.Break() should obey the code though, so in these cases, printing out the info you need or creating a visualization helps more than breakpoints.

Note that Debug.Break() stops execution at the end of the frame (or at some point during the frame, I've never been able to clearly identify the way it works) and not immediately.

 

Yeah, the manual simply states "Pauses the editor."

The subjective feel of Debug.Break() is that when encountered in code, if the Unity Editor was in PLAY mode, it immediately switches to PAUSED mode. Actual code execution continues on ALL objects that would have otherwise run for the rest of that frame, and basically everything runs until the end of frame when the Unity editor checks the PAUSE button again and goes into paused mode.

Using Debug.Break() is NOT a substitution for hitting a true breakpoint, but rather an adjunct to regular breakpoints. Debug.Break() can actually be MORE useful than debugger breakpoints because the editor GUI remains responsive while paused, and you can adjust the scene, tweak stuff, etc., and then continue. When you hit a breakpoint, the editor thread is also frozen unfortunately.