C# String.IsNullOrEmpty: good or bad?

Question

After an incident at work where I misused String.IsNullOrEmpty with a Session variable, a fellow coworker of mine now refuses to accept my usage of String.IsNullOrEmpty. After some research, apparently there's a bug listed for IsNullOrEmpty on MSDN (link) (read note at the bottom):

As of April 4, 2006, there is a bug (possible in the JIT) that makes this method fail when optimizations are turned on. It is known to affect both C# and VB.

More information can be found here (link). Microsoft the bug is 'supposedly' fixed post-Orcas, but unfortunately my employer still uses VS2005. But if the problem is fixed in 2008+ so be it. That's just fine with me.

While my colleague's refusal of my code with IsNullOrEmpty to me is blind ignorance (IMO) he certainly can't tell me why not to use it other than the misuse with the session variable. I've used IsNullOrEmpty all over our code with no issues whatsoever. Personally, I find it much more readable in addition of doing two things in one statement.

After googling for opinions on the subject, I've found sites that take the pros/con stance. Here are some of the sites I've read about this:

https://blog.rthand.com/post/2006/06/22/1063.aspx

http://www.omegacoder.com/?p=105

One site (http://dotnetperls.com/isnullorempty) sums up the method (IMHO) pretty well:

Here we looked that IsNullOrEmpty method on the string type, which provides us with a good and relatively efficient method of checking whether a string is OK to save or use. However, for performance, it may be better to use manual null checks. Empty strings can also be tested in other ways, and my research here shows that checking length is fastest.

Assuming the bug fix is in place (and working correctly) in VS2008/2010/etc., is there any reason not to use String.IsNullOrEmpty with VS2005 and beyond? I realize this may seem a little overkill over such a silly little method, but I'd like to know if there's more behind the scenes going on and if anyone has alternative explanations.

Solution 1

This issue was fixed in .NET 2.0 sp1. There is no reason to avoid its use now.

If you're using .NET 2, you should have sp1 for many other reasons anyways - I see no reason to avoid this for a bug that no longer exists.

Solution 2

I've heard about that bug before, and from what I can gather it never occurs in any real code, only in code like the example that doesn't really do anything. Besides, the bug is not with the IsNullOrEmpty method itself, so it would occur regardless of how you check the string.

If the method does exactly what you want to do, you should use it. However, you should not use it in every situation to check for an empty string. Sometimes you only want to check if the string is empty and not if it's null.

If the string variable is null, this will just skip the code block:

 if (!String.IsNullOrEmpty(str)) { ... }

If the string variable is null, this will cause an exception:

 if (str.Length > 0) { ... }

If the variable is not supposed to be null, you probably want the exception instead of the code treating the null value as an empty string. If something is wrong you want to catch it as early as possible, because it will be harder to track the problem back to the source the longer the exception is from the cause.

Solution 3

you could write a unit test that passes an empty string and one that passes an null string to test this stuff, and run it in VS2005 and after in 2008 and see what happened

Solution 4

We use an extension method for string.IsNullOrEmpty:

public static bool IsNullOrEmpty(this string target)
{
  return string.IsNullOrEmpty(target);
}

Using this approach, even if it were broke in some previous version, a bugfix is only one line of code.

And the added utility of being able to use the method on a string instance that might be null:

string myString = null;
if (myString.IsNullOrEmpty())
{
  // Still works
}

Solution 5

In that bug report in the link you include it states:

This bug has been fixed in the Microsoft .NET Framework 2.0 Service Pack 1 (SP1).

Since that is the case it shouldn't matter if you're using VS 2005 as long as you have SP1 for .NET 2 installed.

As for whether or not to use it, check out this post by CodingHorror.

View more solutions