CType () è sempre l'opzione preferita?

C'è qualche volta in cui CType() è l'opzione corretta rispetto ad altri metodi? Ho riflettuto molto su questo, ma ho voluto porre la domanda nella speranza che ci fosse una risposta alla mia domanda, così posso porre la domanda sul mio posto di lavoro.

La mia idea è che CType() non dovrebbe mai essere usato. Ma altri sembrano pensare che sia ancora in giro per qualcosa di diverso dalla retrocompatibilità. Quindi c'è ancora un uso per questo?

Un grosso problema è che molte persone non sembrano capire la differenza tra Casting and Converting.

Conversione di Vs

Questa era una di queste linee di codice:

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

Se il mio amico leggerà questo, sarà come, "IL MIO CODICE !!!!" lol. Sì, questo è il tuo codice. E come discusso con lui, .Current è un'enumerazione di objZipFile, ma il suo tipo è ZipEntry. Quindi, perché "Converting" con CType() , quando ciò che sta facendo è Casting. Dovrebbe usare DirectCast(.Current, ZipEntry) .

Quindi il modo corretto per trasmettere qualcosa è usare DirectCast() . Ma questa non è una discussione su DirectCast() . Il punto qui è che CType() non dovrebbe certamente essere usato per trasmettere, è uno strumento di conversione, quindi parliamo di più sulla conversione.

A CType () o Not To CType (), non penso sia

Nell'esempio semplicistico, ho una stringa "123" , e voglio che la stringa venga convertita in un intero. Così tante volte, vedi qualcosa del genere:

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

Grande! Funziona! Allora qual è la differenza tra questo e questo:

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

Bene, con questo esatto esempio, la differenza è che CType() ha richiesto più risorse per l'esecuzione. Se ti dessi due drink limpidi e ti dicessi che uno aveva un punteggio di salute di 10, e l'altro di 9. Non scegli il 9 per principio che non è molto meno salutare, scegli la diga 10. Inoltre , la riga Integer.Parse è un paio di caratteri con meno digitazioni.

Ok, ma cosa succede se il tuo input non è "123"? Cosa succede se l'input è "UrMom"? Sento CType() non si romperà ... ma per quanto ne so, non è vero. CType() interrompe tanto quanto Type.Parse() . Mi piacerebbe qualche argomento su questo. Anche se un argomento che supporta la resilienza di CType() da solo non è una ragione sufficiente per utilizzare CType() .

D'altra parte, abbiamo questa opzione in 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

Non solo stiamo analizzando i dati, ma se non li analizza, lo gestiamo correttamente. Questa è un'opzione molto migliore che lancia un Try/Catch attorno al codice errato e lo interrompe prima di gestire il suo fallimento in Catch/Finally .

Tieni presente che potrebbero esserci diversi modi per eseguire il cast e la conversione, ma lo scopo principale di questa domanda è di dimostrare o confutare che CType() semplicemente non dovrebbe essere utilizzato.

Il mio argomento principale è questo ... Gli unici argomenti che ho visto che supportano l'uso di CType() sono quelli che dicono che CType() non si interromperà se i dati sono passati male, o che CType() è migliore se non sei sicuro dei dati che entrano. In risposta a ciò, dico Pish-Posh. Ripensare il codice, posizionare le condizioni e sapere a cosa si desidera utilizzare l'elemento. Se succede qualcosa che non ti aspettavi, gestiscilo correttamente.

Quindi c'è qualche volta che CType() è l'opzione corretta rispetto ad altri metodi? Si prega di fornire esempi.