Do you know of String.IsNullOrEmpty and do you use it? You do? Think again after reading this blog post. Ooops, it might not work and even worse, it might not work only in release (optimized) configuration. Apparently JIT optimizer is to blame. What a nightmare for a developer – the same program might not work deployed at client and worse, the bug is not easy to catch either.
But now, here comes the cherry on the cake. MS recognizes this bug and they will fixes it soon, post Orcas. Note that Orcas is targeted for late 2007 or something.
I guess I’ll have to replace all my String.IsNullOrEmpty calls with text == null || text == string.Empty.
everything is solved with
string s = string.Empty;
if (s.Length == 0)
always declare your string as string.empty and check for length…
Null strings should be in the code if you ask me anyways…
Hi,
You did mean “Null strings should *not* be in the code if you ask me anyways…”
Why not? Null has a special meaning – it means that the string isn’t set. That’s why MS introduced nullable types, too.
And your solution makes potentially unnecessary assignments π
I’ve tested the code. When you do something in the then-part like:
Console.WriteLine(“x is null or empty”);
then everything seems to be OK.
So, it obviously has something to do with optimization.
yeah i meant it “not in the code”
well i hate nulls :))
i think that they shouldn’t exist at all :))
It’s just more work to handle them….
but i also know that they are necesary.
I tend to always declare strings a string.Empty at the begining.
gives me less grief in future development.
Mladen,
Of course, as long as you have a consistent strategy its fine. And apparently your way is good, since you won’t encounter the bug in question π
Hugo,
Yup, seems so, even MS admits it. However, they didn’t say what exactly is going on and how serious it is.
I like nullable strings. Well, used to like them anyway… π
It’s always good to set the string to its initial value, because most of the time you know how you’re going to build it and/or what value it is supposed to hold, when the procedure returns. However, if string is an input parameter to your proc, then you don’t have much choice… I’d prefer “text == null || text.Length == 0” over “text == null || text == string.Empty” though… But I’m nitpicking now…
Note: The last comment was accidently lost. Sorry.