Spot the Bug! – Much Ado about Nothing… (Jonathan Aneja)

Spot the Bug! – Much Ado about Nothing… (Jonathan Aneja)

  • Comments 6

Microsoft has this neat mailing list called “Spot the Bug” where developers can send interesting snippets of code that look correct but actually have subtle bugs in them.  The puzzles are a lot of fun and I’ve always thought it’d be a fun thing to try here on the team blog.  Over the past year or so I’ve been keeping a list of interesting bug reports and emails where people have been tripped up by some of VB’s hidden subtleties (though admittedly many of these could apply to C# as well).

 

The format’s gonna be a bit of an experiment – let me know if you prefer to see the answer in the same post or posted a day later.  Alright let’s get started…

 

Spot the Bug: 

The following code is intended to print “Yes” – will it?

 

        Dim x As Integer? = Nothing

 

        If x = Nothing Then

            MsgBox("Yes: x contains null")

        Else

            MsgBox("No: x does not contain null, and has a real value")

        End If

 

.

 

.

 

.

 

.

 

.

 

Answer:  No!  We’re using the equality operator to compare a nullable integer with Nothing – this results in null propagation, i.e. the result of the expression is Nothing.  An If-statement attempts to convert its condition to a Boolean, so basically we’re left with this:

 

        If Nothing Then

 

        Else

            'Obviously we'll always land here

        End If

 

This can be really surprising when working with nullables, so we’ve decided to add a warning for this case in VB10:

 New null-popagation warning in VB10

 

The warning explains the fix – use “Is” instead of = to avoid the null propagation and get the semantics you expect:

        Dim x As Integer? = Nothing

 

        If x Is Nothing Then

            MsgBox("Yes: x contains null")

        Else

            MsgBox("No: x does not contain null, and has a real value")

        End If

 

Check back for a similar case but with a bit of a twist tomorrow...

Leave a Comment
  • Please add 1 and 2 and type the answer here:
  • Post
  • This kind of puzzles are indeed a lot of fun and very informative. My preference would be to give the answer below the question.

    One thing about this specific example: The opposite of this error is a false compiler which I think is very annoying. When "x" is a reference type, and you don't initialize it,  the expression "x Is Nothing" gets a compiler warning saying: "Variable 'x' is used before it has been assigned a value. A null reference exception could result at runtime.". I think the compiler should also be smart enough to see that you can't get a null reference exception when testing with Is Nothing.

  • Edit: I meant in the comment above: "The opposite of this warning is a false compiler warning which ..."

  • Why did the VB.NET team initially decide to go for 'is' instead of using '=' in ALL comparisons, value type or object? Wouldn't that have been much simpler? Now it's a bit silly, as it's easy to create a bug while the developer clearly wants to do a comparison, so why bother with the extra keyword 'is' ?

  • Hugo - yes that's a known issue, you can work around it by assigning the variable to "Nothing".  I hope we can improve this in VB11.

    Frans - I believe the issue is that "Is" always does reference comparisons, and if an object had an overloaded equals operator it wouldn't be possible to call it using "Is".  With Is and = you can either call the operator or do reference comparison.  They may have been reasons related to back-compat as well.

  • "Spot the Bug" is a great idea.  We get to challenge our knowlege and learn something useful, usually all at the same time.

  • Don't you think you should check x.HasValue?

Page 1 of 1 (6 items)