Yea, we have heard that request before... here is a method we are looking at adding a the Whidbey release of the .NET Framework on the System.String class. 

 public static bool IsNullOrEmpty(string str)

what do you think?

[Brad Abrams]

"The method might seem convenient, but most of the time I have found that this situation arises from trying to cover up deeper bugs.

Your code should stick to a particular protocol on the use of strings, and you should understand the use of the protocol in library code and in the code you are working with.

The NullOrEmpty protocol is typically a quick fix (so the real problem is still somewhere else, and you got two protocols in use) or it is a lack of expertise in a particular protocol when implementing new code (and again, you should really know what your return values are)."
[Miguel de Icaza]

I agree that there is potential for misuse, but this doesn't mean it isn't a good idea by any means. In certain places, my BLL code should be robust enough to know that an empty string input from the UI layer is the same thing as a null value, regardless of how it ends up in the DB (most likely as DBNull like it should be).

Should I force the developers using my code to write nice little conversion statements all over their UI layer like "emailAddress == String.Empty ? null : emailAddress"? Or should I realize that if they give my code a blank email address that they are giving me nothing, not a malformed email. I could spit back an error that says "Email Address is not in the proper format," but that is not true, the fact is that they didn't give me any email address (so if I needed one, I should spit back a more descriptive error that says, "you must give me an email address" instead).

Considering that languages like VB.NET blur the distinction between string and null, it is quite possible that the morts who are calling into my code might not even realize that there is a physical difference between an empty string and a null value. Making my code smart enough to adapt to these circumstances where it makes sense produces code that is a lot easier to interface with and saves a lot of developers a lot of time (as does using XP and VS.NET rather than Gnome and VI(M)).

I vote that we let Microsoft keep designing and Ximian keep cloning, things are better that way :-).


  • "that languages like VB.NET blur the distinction between string and null"

    How does it do that?

    Dim emailAddress As String

    if emailAddress Is Nothing Then

    'it is null

    elseif emailAddress = String.Empty Then

    'it is empty

    end if

    where is the blur?

  • I actually went back and read your previous posts, and I see where it might seem confusing, but object references in VB.NET are compared using Is, not = ... Likely could catch someone new to VB I suppose, but it had never occured to me to compare objects using =.

    I'm actually surprised that comparing a String and Nothing using = is allowed if Option Strict and Option Explicit are both set to On... but it appears to be the case.

    Anyway, Null and Empty are two very different states, and Is allows you to determine between them. I'd have to ask the VB guys if the = Nothing was added as a specific "feature" because it looks a lot like an implicit conversion of Nothing to an empty String to me. (Convert.ToString(null/nothing) = String.Empty, which I why I am wondering if this is a case of an implicit conversion.)

  • Good idea!
    P.S. A U realy girl?

Comments have been disabled for this content.