Advantage of TryParse by ThinqLinq

Advantage of TryParse

I recently had the opportunity of showing the Altanta VB group the advantages of using the new TryParse method introduced in .Net 2.0. The presentation materials along with a sample project are available at the group's website.

In early versions of .Net, in order to check the validity of a data type, you had to go to some excess measures. There are a number of options:

1) Don't check the data. The user wouldn't be silly enough to try to type their name in a date field, or would they. Oh, they typed "1=0'drop table employees" in the order number field... oh well. I'll try casting it anyway. What do you mean InvalidCastException thrown? Seriously, if you consider this an option, you need to be working in another field.

2) As an alternative, you can try to cast the value into the desired data type (ex. Integer.Parse(MyValue)). The downside to this option is the fact that you need to wrap the parse inside of Try..Catch block. This option may be viable if you are not processing millions of values and require any performance, or if the use of an invalid data type is indeed an exceptional case. If dealing with user entered values, it is better to assume that the user is NOT going to enter the expected values and thus an invalid user entry is not an exceptional situation. As I will demonstrate shortly, the performance of this option is reasonable when a valid value is entered, but astoundingly unacceptable when an invalid value is entered (eg. trying to cast "a" as an Integer).

3) Use the VB IsNumeric or IsDate methods to check your values prior to working with them. This gives a level of protection. You can still get overflow exceptions and other potential problems. In addition, the VB 1.x internally uses the above method of simply wrapping an attempt to parse within a try catch block. The 2.0 implementation uses the prefered method of TryParse internally. There is a small performance penalty using this wrapper, but the main performance penalty is caused by a double casting of the value that is required if you want to test the value and then set it. Here is a sample implementation using IsNumeric:

Dim MyTestValue as String = "A"
Dim MyWorkValue as Integer
If IsNumeric(MyTestValue)
MyWorkValue = Integer.Parse(MyTestValue)
End If

The real issue here is the internal implementation of IsNumeric on 2.0 as seen below

If Dim text1 As String = TryCast(Expression,String)
If (Not text1 Is Nothing) Then
Dim int1 As Integer
Return Conversions.TryParseInteger(text1, int1)
'Note, we just throw away the result of int1
End If
End If
Return False

Here, you can see that the value is parsed interally, but the resulting value is just thrown away. Why not simply use the TryParse method directly as follows:

Dim MyTestValue as String = "A"
Dim MyWorkValue as Integer

If Integer.TryParse(MyTestValue, MyWorkValue) then

'do the processing of the value

End If

Because MyWorkValue is passed ByRef, the value is set to the parsed version and you can work with it. If the parse does not succeed, the value is left at it's previous value and you can save cycles by not having to worry about processing values if it is not a valid value anyway. A comparison of the various options clearly show that TryParse is the best option. My sample test rig show the following results:





I encourage you to test these results yourself. Feel free to download my samples and let me know any errors or ommissions I made.

Posted on - Comment
Categories: VB -
comments powered by Disqus