Question

Let’s say I have this sub in VB.NET:

    ''' <summary>
    ''' Validates that <paramref name="value"/> is not <c>null</c>.
    ''' </summary>
    '''
    ''' <param name="value">The object to validate.</param>
    '''
    ''' <param name="name">The variable name of the object.</param>
    '''
    ''' <exception cref="ArgumentNullException">If <paramref name="value"/> is <c>null</c>.</exception>
    Sub ValidateNotNull(ByVal value As Object, ByVal name As String)
        If value Is Nothing Then
            Throw New ArgumentNullException(name, String.Format("{0} cannot be null.", name))
        End If
    End Sub

Is it proper to call this ValidateNotNull (which is what I would call it in C#) or should I stick with Visual Basic terminology and call it ValidateNotNothing instead? Also, in my exception, is it proper to say “cannot be null”, or would it be better to say “cannot be Nothing”?

I sort of like the way I have it, but since this is Visual Basic, maybe I should use Nothing. But since the exception itself is called ArgumentNullException, it feels weird to make the message say “cannot be Nothing”.

Answer 1

I think you’re fine sticking with Null. It’s not without precedent. For example, the .NET framework developers didn’t create String.IsNothingOrEmpty for the VB community. And it also isn’t like Null is some vague concept, anyone who has programmed or worked with a database for longer than a week has seen it.

With that in mind, it’s OK to consider your audience. If your code is going into a class library that can be used by other developers, those developers may be accustomed to seeing null as null. On the other hand, if this is strictly part of some codebase that will only be maintained, then the VB folks looking at it may expect to see “Nothing.” Conform to standards as best you can, but know that the standards of your language may not necessarily be the standards of your consumers.

But as said earlier, Null should be fine.