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.