Spot the Bug! – Much ado about Nothing… Part 2! (Jonathan Aneja)

Spot the Bug! – Much ado about Nothing… Part 2! (Jonathan Aneja)

  • Comments 11

In yesterday’s post we saw that the use of the wrong comparison operator with Nothing in an If block can lead to surprising results.  Let’s look at a slightly different case today:

 

        Dim x As Integer = Nothing

 

        If x = Nothing Then

            MsgBox("A true statement - we land here")

        Else

            MsgBox("The statement is a lie - we land here")

        End If

 

What gets printed?  If the code is intended to print “A true statement…”, is there actually a bug in this code?

 

 

.

 

.

 

.

 

.

 

.

 

Answer:  The code is correct according to its “specification” (I’m using the term loosely here J), so from a technical point of view there is no bug here.   However, from a code readability and maintenance point of view, I’d argue that there is a bug.

 

The Nothing literal in VB means “default value for this type”, and for an Integer that would be 0.  So the code above is exactly equivalent to this:

 

    Dim x As Integer = 0

 

    If x = 0 Then

        MsgBox("A true statement - we land here")

    Else

        MsgBox("The statement is a lie - we land here")

    End If

 

Now that’s way more readable than the version above, and dramatically reduces the potential for confusion.  In general*, if you ever find yourself writing “= Nothing” in a conditional expression, you should either be changing the = to “Is” (as we saw yesterday), or you should change Nothing to the actual default value if possible. 

 

The next post will have a real bug, I promise J

 

*Yes, there may be cases such as structure/generics/overloaded operators where you actually would want to say “= Nothing” – my point is that if you’re going to do this make sure you know what you’re doing, and insert a comment so that those reading your code also know what you’re doing J.

Leave a Comment
  • Please add 5 and 1 and type the answer here:
  • Post
  • I didn't know “Nothing means: default value for this type”. Probably because in C# Nothing is null and in SQL "= null" always evaluates to null, I thought we would end in the else part.

    Learnt something here, thanks!

  • The fact that nothing can be legally assigned to a value type is a serious problem.

  • I agree with jason.  Having a value type evalute to nothing is not good.  It is not a dynamic variable that just gets created on the heap. I gets created on the stack and will always evaluate to something even if that something for and int is the number 0.  To avoid confusion, value types should not even be able to be used with the nothing keyword.

  • I always thought it strange that VB.net does not acctually initialize value types until they are assigned. For example in the above example if you do not assign the int to nothing then it does treat the int as nothing.

  • Jason, Novlok;

    I don't know if such a restriction is necessary.

    Whether equating Nothing with defaultness is logically valid I might argue is contextual.

    From a language (English) perspective would we not say that a free item costs Nothing (it doesn't cost anything) or would you say it cost $0.00?

    In the case of strings "" and Nothing compare as equal to the VB comparison operator and Len("") = Len(Nothing), And Len(Nothing) = Len(<empty array>).

    Furthermore System.Char is a value type (structure) and its default value is ChrW(0) - commonly called the null character. The only way to represent this as a literal in Visual Basic (other than the above function) is to assign it Nothing. In this context assigning Nothing to a value type sets it to the "null" character so it makes sense, no?

    Conceptually a glass doesn't contain 0 liters of water - it's empty - there's Nothing in the glass.

    So from another angle Emptiness, Nullness, and Nothingness are sufficiently synonymous that I wouldn't say the usage is inherently unsensible or "not good" though I would generally avoid this usage when a more meaningful default value (or literal, such as 0) can be used instead.

    -------------

    Steve,

    What's strange about a variable taking on its default value unless otherwise assigned? That's the entire meaning of a *default* value. What's strange is that other languages make you initialize redundantly, no?

  • Re: "The fact that nothing can be legally assigned to a value type is a serious problem"

    and

    "To avoid confusion, value types should not even be able to be used with the nothing keyword."

    The logical implication of both those statements is that "it should be illegal to initialize a value type to its default value", which I'm sure we'd all agree is not a good idea :)

    Consider the following code in C#:

    int x = default(int);

    IntPtr y = default(IntPtr);

    Process p = default(Process);

    The following VB is *exactly* equivalent to those lines:

    Dim x as Integer = Nothing

    Dim y As IntPtr = Nothing

    Dim p As Process = Nothing

    Nothing just means "default value for type", not necessarily null.

  • Anthony, you miss understod what I was trying to say.

    AS the example shows if you do dim x as int = nothing then x=0 if you don't intialize the variable dim x as int then X<>0 it does equal nothing.

  • Steve,

    I'm not sure I follow. The example is meant to show that for comparison puposes over non-nullable Integers Nothing and 0 are equivalent. Could you explain how you are noticing this difference in your code? Please be detailed.

  • I really doubt that I will ever use something like this, but it can't hurt to know how it works.

  • I prefer not to use "nulls" or "Nothings" for numeric variables (I prefer 0 or -1 for detecting errors or invalid values). You're right, "Nothing" is confusing.

  • I have to be anonymous here in case it's a breach of NDA, but "= Nothing" came up in a recent MCP exam as part of the code sample.  I also think it was a bug, but I'm not sure as obviously I wasn't allowed to take a copy out of the room with me.  I believe it's a case of mistranslation from C#.

Page 1 of 1 (11 items)