Parameter data type verification in VB .net

[IlyaRabyy]

Colleagues,

It's been awhile since I worked in VB last time (~14 years), and came back to it (now in .NET "incarnation") just now.
I forgot many simple things about VB. I could find some on the MS's website, but not all.
And - alas! - my access to the development environment is heavily restricted (company's policies), and I cannot just write some quick-n-dirty sample code and try it in VS 2012 IDE.
So, my questions here might look stupid - my apologies, please bear with me.
To the matter at hands.
One of the things that I can't remember, neither find in the MS Docs website is what subject line says.
Say, you are writing a function, and the parameters' data types are set, e.g.

Function MyFunc(ByVal cStr As String, ByVal iLen As Integer)

and what happens if the calling code passes argument of incorrect data type? Say, NULL/Nothing instead of a String?
System will throw it's error message, right?
So, to prevent that, I want to first verify if that parameter is indeed of type String.
Will the following code do that?

Function MyFunc(ByVal cStr As String, ByVal iLen As Integer) As String
If cStr.IsNullOrEmpty() Then
   MsgBox("Invalid parameter passed: cStr must not be NULL or empty", 16, "Code Error")
   Return Space(0)
End If

Or it will err and throw error message box on its own before reaching that If?

TIA!

Regards,

Ilya

 

[Andrzejek]

This works OK (123 is converted to String):

Public Class Form1
    Private Sub Button1_Click(sender As Object, e As EventArgs) Handles Button1.Click
        MsgBox(MyFunc([blue]123, 652[/blue]))
    End Sub
    Function MyFunc([blue]ByVal sStr As String, ByVal iLen As Integer[/blue]) As String
        Return sStr & " - " & iLen
    End Function
End Class

This will give you a run time error: Conversion from string "A String" to type 'Integer' is not valid.

Public Class Form1
    Private Sub Button1_Click(sender As Object, e As EventArgs) Handles Button1.Click
        MsgBox(MyFunc(123, [red]"A String"[/red]))
    End Sub
    Function MyFunc(ByVal sStr As String, [red]ByVal iLen As Integer[/red]) As String
        Return sStr & " - " & iLen
    End Function
End Class

---- Andy

There is a great need for a sarcasm font.

 

[IlyaRabyy]

Right! Err it will.
However, my Q. was about preventing this error from happening.
I didn't know that VB .NET 2012 has that VarType() function I used so many times in VFP for that very purpose: parameter data type verification! I found it just now.
So, in your example, it s./b. something like this

Public Class Form1
   Private Sub Button1_Click(sender As Object, e As EventArgs) Handles Button1.Click
      MsgBox(MyFunc(123, "A String"))
   End Sub
   Function MyFunc(ByVal sStr As String, ByVal iLen As Integer) As String
      If VarType(sStr) <> vbString Then
         MsgBox("Invalid parameter passed: cStr must be of type String", 16, "Code Error")
         Return ""
      ElseIf VarType(iLen) <> vbInteger Then
         MsgBox("Invalid parameter passed: iLen must be of type Int", 16, "Code Error")
         Return ""
      Else         
         Return sStr & " - " & iLen
      End If
   End Function
End Class

Have I missed anything, colleague?

Regards,

Ilya

 

[Andrzejek]

Hopefully somebody smarter than me jumps in and correct me, but – if there is a possibility to pass wrong variable type (why would that happen in your code?) - you may want to examine your variables before you call the Function:

Public Class Form1
   Private Sub Button1_Click(sender As Object, e As EventArgs) Handles Button1.Click
      If VarType(sStr) <> vbString Then
         MsgBox("Invalid parameter passed: cStr must be of type String", 16, "Code Error")
         Exit Sub
      ElseIf VarType(iLen) <> vbInteger Then
         MsgBox("Invalid parameter passed: iLen must be of type Int", 16, "Code Error")
         Exit Sub
      End If

      MsgBox(MyFunc(123, "A String"))
   End Sub
   Function MyFunc(ByVal sStr As String, ByVal iLen As Integer) As String
      Return sStr & " - " & iLen
   End Function
End Class

---- Andy

There is a great need for a sarcasm font.

 

[IlyaRabyy]

The data may come from different places, colleague.
If it's coming from a GUI screen (Win or Web form) - yes, you can "cull" it right there.
However, if it comes from, say, a DB table, from a field where NULL is allowed (1st thing that comes to mind), and you are developing a generic function for a library... I hope you understand what I am talking about.
And anyway, it's better be safe than sorry, wouldn't you agree?
Thank you for your help colleague, I appreciate your advises (really!)

Regards,

Ilya

 

[Andrzejek]

Aaa..., if you are talking "a generic function for a library" (where "generic" is a key word) how about a Function where you accept Objects, and then examine what you've got and if you can convert (CAST?) them to something useful




---- Andy

There is a great need for a sarcasm font.

 

[IlyaRabyy]

Actually, colleague, the thought did occur to yours truly!
But that's the task for another day.
Right now I'm designing an equivalent to the VFP's CHRTRAN() function ("Character Transpose") in VB.
(When I was teaching programming in VB6 in a private IT school (t'was 1997-2000), I used to give my students assignments like that, to write in VB6 a function simulating some VFP's function VB6 didn't have.)
New VB does have already equivalent of VFP's STRTRAN() function in String.Replace(), but not String.CharReplace...
And we need it now here, coz what we find in the data clients send to us... And "Customer's always right!" - right?

Regards,

Ilya

 

[Andrzejek]

Yeah, right... That’s what we tell the customer, but you know what we really think…

I feel your pain. The garbage you find in the data, and no matter how much programing you do to fix it, there is more garbage to fix. It is an on-going battle.

Good luck.



---- Andy

There is a great need for a sarcasm font.

 

[jebenson]

You could put a Try...Catch block around the call to the function:

Try

MyFunc(123, "String")​

Catch ex As Exception

MsgBox(ex.Message)​

End Try

You can get a lot of information about the exception thrown via the Exception object (ex). In the Catch code you can take various actions, like logging the exception or shooting off a message to a responsible party. The good thing about this is you don't have to try to check for every single input type that could cause an error. And, the code will keep executing rather than breaking on the line with the error.

I used to rock and roll every night and party every day. Then it was every other day. Now I'm lucky if I can find 30 minutes a week in which to get funky. - Homer Simpson

Arrrr, mateys! Ye needs ta be preparin' yerselves fer Talk Like a Pirate Day!