CType () é sempre a opção preferida?

Existe algum momento em que CType() é a opção adequada sobre outros métodos? Pensei muito sobre isso, mas queria colocar a questão na esperança de que houvesse resposta à minha pergunta para que eu pudesse colocar a questão no meu local de trabalho.

Minha ideia é que CType() nunca deve ser usado. Mas outros parecem pensar que ainda existe algo diferente de compatibilidade retroativa. Então, ainda há um uso para isso?

Um grande problema é que muitas pessoas não parecem entender a diferença entre Casting e conversão.

Convertendo Vs Casting

Essa era uma dessas linhas de código:

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

Se meu amigo ler isso, ele dirá: "MEU CÓDIGO !!!!" ri muito. Sim, este é o seu código. E como eu discuti com ele, .Current é uma enumeração de objZipFile, mas seu tipo é ZipEntry. Então, por que ele está "Convertendo" com CType() , quando o que ele realmente está fazendo aqui é Casting. Ele deveria estar usando DirectCast(.Current, ZipEntry) .

Portanto, a maneira correta de transmitir algo é usar DirectCast() . Mas isso não é uma discussão sobre DirectCast() . O ponto aqui é que CType() certamente não deve ser usado para o Cast, é uma ferramenta de conversão, então vamos falar mais sobre a conversão.

Para CType () ou Não para CType (), eu não penso assim

No exemplo simplista, tenho uma string "123" e quero que a string seja convertida em um Integer. Tantas vezes, você vê algo assim:

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

Ótimo! Funciona! Então qual é a diferença entre isso e isso:

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

Bem, com esse exemplo exato, a diferença é que CType() levou mais recursos para ser executado. Se eu lhe der dois drinques claros e disser que um deles tinha um índice de saúde de 10, e o outro de 9. Você não escolhe o 9 a princípio que não é muito menos saudável, você escolhe a barragem 10. Também , a linha Integer.Parse é um par de caracteres com menos digitação.

Ok, mas e se sua entrada não for "123"? E se a entrada for "UrMom"? Eu ouço CType() não vai quebrar ... mas, tanto quanto eu sei, isso não é verdade. CType() divide tanto quanto Type.Parse() . Eu gostaria de alguns argumentos sobre isso. Embora um argumento que suporte apenas a resiliência de CType() não seja motivo suficiente para usar CType() .

Por outro lado, temos essa opção na 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

Não só estamos analisando os dados, mas se não analisarmos, estamos lidando com isso corretamente. Qual é uma opção muito melhor que lançar um Try/Catch em torno do código incorreto e deixá-lo quebrar antes de manipular sua falha no Catch/Finally .

Tenha em mente que pode haver várias maneiras diferentes de transmitir e converter, mas o objetivo principal desta pergunta é provar ou refutar que CType() simplesmente não deveria ser usado.

Meu principal argumento é este ... Os únicos argumentos que eu vi que suportam o uso de CType() são aqueles que dizem que CType() não vai quebrar se passarem dados ruins, ou que CType() é melhor se você não tem certeza dos dados que entram. Em resposta a isso eu digo Pish-Posh. Repense seu código, coloque condicionais e saiba para que você está querendo usar o item. Se acontecer algo que você não esperava, trate-o corretamente.

Então há algum tempo CType() é a opção apropriada sobre outros métodos? Por favor, forneça exemplos.