string.IsNullOrEmpty returns true when supplied st

问题:

I have a unit test that calls a method on an object passing in a string.

One of the first things that the method being called does is to check the string for null or empty.

However, no matter what the value of filePath is, the call to string.IsNullOrEmpty is true. See image below.

Am I missing something here?

EDIT:

Checking for null and string.Empty separately works as expected:

EDIT 2:

I have cleaned the solution, deleted the bin directory via the file system and still, after a rebuild, the debugger shows that the ArgumentNullException should be being thrown, although it actually is not being thrown.

回答1:

The contents of filePath are definitely not null (and not empty), so that leaves us with two options:

• You have a wider scope variable (i.e. global variable) named filePath, which is empty on null
• Your debugger is referencing an older version of the binaries. In that case, claear and rebuild the solution

Update

Your question update makes me think the second option (of the above) is the one

回答2:

I'm also experiencing this in Visual Basic with If String.IsNullOrEmpty(foo). I agree with Andrei's comment, this seems to be a bug with how the debugger is visualizing this particular construct.

Clean/Rebuild did not affect it. Interestingly, if you add a more complex body to your If statement, the debugger will only pause (i.e. yellow arrow) on the last line of the body. It does not actually execute the line of code.

It would be interesting if someone could gives us some insight as to why this happens.

Here is the code where I'm seeing this:

Notice the debugger arrow is on the line e.Cancel = True, even though myItem.Subject is not null. When I press F10, the arrow will advanced to the ElseIf statement and e.Cancel will still be False.

Also, while the debugger is on this line, I cannot drag the arrow to a different line like I usually can. If I attempt to move to another line by dragging the yellow arrow, I get the following error:

回答3:

This is the first time I have come across this issue.

The way we stepped round it for now is to add the following on the back of the IF statement.

#if DEBUG
            else
            {
                // A hack to fix the debugger issue on the IsNullOrEmpty statement above.
            }
#endif