C# String.IsNullOrEmpty: good or bad?

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 fo开发者_C百科und 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.

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.

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.

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

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.

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
}

When implementing argument checking in APIs, I usually check for each condition separately and throw different exceptions: ArgumentNullException for a null reference or, depending on the API specifications, ArgumentException for an empty string. In this case, using String.IsNullOrEmpty doesn't allow you to distinguish between these two separate error conditions.

if (str == null)
{
    throw new ArgumentNullException("str");
}
if (str == string.Empty)
{
    throw new ArgumentException("The string cannot be empty.", "str");
}

I am pretty sure it was fixed on the SP1 but anyway you can create your own null or empty method :)

As with any language or portion thereof, it's all about knowing the pros/cons and making an educated decision based on that information. IMHO.

If it is broken in your version, then it is trivial to just have a static method that will do the check, so just do:

public static bool isNull(String s) {
  return s == null || s.trim().length == 0;
}

No point in getting into a big issue over something that should be relatively easy to fix.

You don't need to change it everywhere, though you can do a global replace of one static method with another.

I wonder why people use string.Empty, it's not a good thing because it's an initialized string & this concept exists only in .Net frame everywhere this is a valid string with len of 0(db servers make very clear destinction between this and will complain if you have logic checking for null but you get and empty string). I think that string.IsNullOrEmpty is one of the top 5 worst practices/functions I have ever seen because somehow it encourages/makes it look ok people to init their strings and can be treated as null. This function should have never been added and I think the .Net guys should try to phase it out:) Who needs and empty string anyway ? I've never used it unless I had to because of existing projects used it