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 CastingThis was one such line of code:With objZipFile.GetEnumerator()    While .MoveNext        objZipEntry = CType(.Current, ZipEntry)         all this work is done with the objZipEntry    End WhileEnd WithIf 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 soIn 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 = 0result = CType(123, Integer)Great!  It Works!  Then what is the difference between that and this:Dim result as Integer = 0result = 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 = 0Dim TryInt As Integer = 0If Integer.TryParse(54, TryInt) Then    MyInt = TryInt Else    'Handle it appropriately End IfNot 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.
Is CType() ever the preferred option?
coding standards;vb.net
Edit: This question/answer pair were during a C++/C# developer's short stint in the confusing world of Visual Basic.  It turns out that the proper answer is: Don't use Visual Basic. At this time, the best support for CType() is a VB6 to early .NET support document from 2003. EndEditAfter allowing this question to live online for a while, and also working with peers on research and usage regarding Casting and Converting, the answer has become clear.The question was: Is there any time CType() is the proper option over other methods?The answer is: No.  From this point on, never use CType().The only argument is: What if you don't know the type you're casting?The counter argment to that is: Then refactor your program, be more explicit with your intentions, and perhaps stop using weak-typed objects, strong-typed datasets, or datasets in general.