unexpected behavior with ctype and nullable byte (byte?) variable

[BruceG]

Hello - I had an issue that I have now corrected, but I'd like to understand why the original way I had this behaved as it did.
Original way:

    Dim b As Byte?
    Dim s As String = " "     ' s will either contain a blank space or a digit between 0 and 3
    b = CType(if(s = " ", Nothing, s), Byte?)

When the above code executed, I expected the variable b to be null (Nothing), however, it contained zero (0).

The fix:

    Dim b As Byte?
    Dim s As String = " "     ' s will either contain a blank space or a digit between 0 and 3
    b = If(s = " ", Nothing, CType(s, Byte?))

When the above code executed, b was Nothing as one would expect.

The question is why did the first example return 0 rather than Nothing?

[jmcilhinney]

The If operator that you're using is effectively generic, in that the two potential return values must be the same type or one must be a type derived from the other. In your first code snippet, you have this:

if(s = " ", Nothing, s)

so that If operator is returning a String, i.e. either a null reference of type String or the value of s. The CType operator is then converting that String reference to a Byte? and it appears that the result of using CType to convert a null String reference to a nullable numeric type is always zero. I tried it with Integer? as well and got the same result. In the second case, because the last argument to If is type Byte?, the second argument is inferred to be that type too, so that Nothing is going directly to type Byte?, rather than to String first and then to Byte?. It seems to be a bit of an idiosyncratic behaviour but it is what it is.

[BruceG]

Thanks, jmcilhinney. Your response further confirms and clarifies what has been observed here.
Easier to understand is the behavior of the If function ("two potential return values must be the same type ...").
The CType situation is, as you say, more idiosyncratic: "it appears that the result of using CType to convert a null String reference to a nullable numeric type is always zero". Prior to posting on here, I did try to find an "official statement" on this behavior but was unable to do so.

[PlausiblyDamp]

Thanks, jmcilhinney. Your response further confirms and clarifies what has been observed here.
Easier to understand is the behavior of the If function ("two potential return values must be the same type ...").
The CType situation is, as you say, more idiosyncratic: "it appears that the result of using CType to convert a null String reference to a nullable numeric type is always zero". Prior to posting on here, I did try to find an "official statement" on this behavior but was unable to do so.

I have always tended to avoid CType, instead I prefer the Parse / TryParse methods provided by a lot of the built in types. Also the Convert class might save a more expected behaviour.

[dbasnett]

I have always tended to avoid CType, instead I prefer the Parse / TryParse methods provided by a lot of the built in types. Also the Convert class might save a more expected behaviour.

Agreed.

            ' s will either contain a blank space or a digit between 0 and 3
            If s.Length = 1 AndAlso Byte.TryParse(s.Trim, Nothing) Then
                b = Byte.Parse(s)
            End If

Tested with

        For Each s As String In {" ", "0", "1", "2", "3"}
            ' s will either contain a blank space or a digit between 0 and 3
            If s.Length = 1 AndAlso Byte.TryParse(s.Trim, Nothing) Then
                b = Byte.Parse(s)
            End If
        Next

[jmcilhinney]

I would tend to agree with my fellows above about avoiding CType. In fact , I never use CType directly. I do use CStr, CInt, etc, to perform a cast, as it's more succinct than using DirectCast for those supported types, but I never use them or CType to perform a conversion. I think that that's partly because I have long tended to use C# as much or more than VB and there's no CType in C#, so I tend to write the same code in VB as I would in C#.

[BruceG]

Thanks for all your input gentlemen, good advice all around.