VB.NET Coding Standards – Is CType() Ever the Preferred Option?

Is there any time CType() is the proper option over other methods? I did plenty of thinking on this myself, but wanted to put the question in hopes there would be answer to my question so I can put the question to rest in my workplace.

My idea is that CType() should never be used. But others seem to think it's still around for something other than backward-compatibility. So is there still a use for it?

A big problem is that many people don't seem to understand the difference between Casting and Converting.

Converting Vs Casting

This was one such line of code:

With objZipFile.GetEnumerator()
    While .MoveNext
        objZipEntry = CType(.Current, ZipEntry)
        … all this work is done with the objZipEntry
    End While
End With

If my buddy ever reads this, he'll be like, "MY CODE!!!!" lol. Yes, this is your code. And as I discussed with him, .Current is an enumeration of objZipFile, but its type is ZipEntry. So why is he "Converting" with CType(), when what he's really doing here is Casting. He should be using DirectCast(.Current, ZipEntry).

So the proper way to Cast something is to use DirectCast(). But this isn't a discussion about DirectCast(). The point here is that CType() Should certainly not be used to Cast, it's a Conversion tool, so let's talk more about Converting.

To CType() or Not To CType(), I don't think so

In the simplistic example, I have a string "123", and I want the string to be converted to an Integer. So many times, you see something like this:

Dim result as Integer = 0
result = CType("123", Integer)

Great! It Works! Then what is the difference between that and this:

Dim result as Integer = 0
result = Integer.Parse("123")

Well, with that exact example, the difference is that CType() took more resources to run. If I gave you two clear drinks and told you one had a health rating of 10, and the other of 9. You don't choose the 9 on principle that it isn't that much less healthy, you choose the dam 10. Also, the Integer.Parse line is a couple characters of less typing.

Okay, but what if your input isn't "123"? What if the input is "UrMom"? I hear CType() won't break… but as far as I know, that isn't true. CType() breaks just as much as Type.Parse(). I'd like some arguments on that. Though an argument supporting CType()'s resilience alone isn't reason enough to use CType().

On the other hand, we have this option in the Type-Class:

Dim MyInt As Integer = 0
Dim TryInt As Integer = 0
If Integer.TryParse("54", TryInt) Then
    MyInt = TryInt 
Else
    'Handle it appropriately 
End If

Not only are we parsing the data, but if it doesn't parse, we are handling it correctly. Which is a much better option that throwing a Try/Catch around bad code and letting it break before handling its failure in the Catch/Finally.

Keep in mind, there may be multiple different ways to cast and convert, but the main purpose of this question is to prove or disprove that CType() simply shouldn't be used.

My main argument is this… The only arguments I've seen that support the use of CType() are those that say CType() won't break if passed bad data, or that CType() is better if you are unsure of the data going in. In response to that I say Pish-Posh. Rethink your code, place conditionals, and know what you're wanting to use the item for. If something happens that you weren't expecting, handle it correctly.

So is there any time CType() is the proper option over other methods? Please provide examples.