When .NET 1.0 was released, VB and C# were very similar. But with the fourth version nearing release, the differences are really mounting. Today we look at the subtle differences in nullable types that can trip up developers.
Nullable types were introduced with .Net 2.0. Using generics, any value type can be wrapped in Nullable
C# immediately added language support for nullable types. VB, still dealing with the fallout from the VB to VB.Net transition, was unable to do likewise. Nullables can still be used, but only at the API level.
With version 9, Visual Basic will add full support for nullable types. It will use a syntax nearly identical to C#, but with very different semantics. With C#, comparison operations always returns a true or false. In VB, nulls are propagated and thus a comparison may return true, false, or null.
| a=null, b=null | ||
| Operator | C# Result | VB Result |
| == | true | Nothing |
| != | false | Nothing |
| > | false | Nothing |
| < | false | Nothing |
| >= | false | Nothing |
| <= | false | Nothing |
| a=1, b=null | ||
| Operator | C# Result | VB Result |
| == | false | Nothing |
| != | true | Nothing |
| > | false | Nothing |
| < | false | Nothing |
| >= | false | Nothing |
| <= | false | Nothing |
These tables show an interesting anomaly in C#. While a==b returns true when both are null, a>=b and a<=b return false.
When it comes to checks requiring Booleans, C# is clear. VB, on the other hand has to somehow map its three-state logic to a Boolean value. It does this by equating null with false for the purpose of Boolean checks like If, While, and Until. This can lead to surprising results of its own.
a = null, b = null
If a=b Then
'skipped
Else
'this line is executed
End if
If Not (a=b) Then
'skipped
Else
'this line is executed
End if
Both (a=b) and Not (a=b) return a null, and thus are considered to be false.
Knowing these differences and inconsistencies by heart is essential for developers working with nullable types in either language, lest subtle bugs be introduced.
Community comments
I feel a new pattern coming on...
by John DeHope,
Re: nullable types in VB
by Jonathan Allen,
I feel a new pattern coming on...
by John DeHope,
Your message is awaiting moderation. Thank you for participating in the discussion.
The first thing this makes me think, in VB.Net I'd probably start to write code like c# pseudocode...
switch ( <possibly null boolean expression> )
{
null:
// code to handle null outcome here
true:
// code for handling true
false:
// code for handling false
}
Really this just enforces in my mind how much we need a way to say a reference cannot be allowed to be null. They added a way to make a structures nullable, but not a way to make objects not nullable. I'd like to normalize the behavior. Today we say that "Dim i As Integer" means that i must always hold an integer value, never null. But then we go around and say "Dim s As String" allows s to be null or to have a value. This is annoying! I think we need it to be one way for both structures and objects, and we need the same syntax for declaring references that cannot be null. Something like...
Dim i as integer // i cannot be null
Dim i as integer? // i might be null
Dim s as string // s cannot be null
Dim s as string? // s might be null
Same assumptions, same syntax.
Re: nullable types in VB
by Jonathan Allen,
Your message is awaiting moderation. Thank you for participating in the discussion.
It is important to understand that Nothing is a keyword, not a value. The Nothing you assign to an Integer is not the same Nothing you assign to an Integer?.