Respuesta.

En Visual Basic, los datos a menudo se ingresan como cadenas (por ejemplo, a través de TextBox o InputBox), sin embargo, para seguir trabajando se requiere convertirlas en tipos numéricos. En versiones anteriores de VB se utilizaba una conversión no estricta mediante Val o CInt, lo que conducía a errores explícitos e implícitos con datos incorrectos. Se asumía que la cadena siempre contenía un valor correcto, pero en la práctica, los usuarios ingresan símbolos erróneos, lo que provoca errores o conversiones incorrectas.

El problema es la falta de protección en la conversión, que puede llevar al fallo de la aplicación o a cálculos erróneos. Por ejemplo, Val("1a") devolverá 1, lo cual puede ser inesperado. Usar TryParse y una verificación estricta del formato de entrada ayuda a evitar estos errores y manejar correctamente la entrada.

La solución es aplicar el método Integer.TryParse (o Double.TryParse, etc.), que devuelve True solo en caso de conversión exitosa.

Ejemplo de código:

Dim input As String = TextBox1.Text
Dim value As Integer
If Integer.TryParse(input, value) Then
    ' Se ha ingresado un número correcto, la variable value contiene el valor
Else
    MessageBox.Show("Por favor ingrese un número entero")
End If

Características clave:

TryParse maneja errores de manera segura, no lanza excepciones
Val y CInt no son adecuados para datos de usuario sin verificación
Es importante considerar la localización (separadores de la parte decimal), utilizar sobrecargas correctas de TryParse

Preguntas capciosas.

¿Cuál es el peligro de la función Val al manejar la entrada del usuario?

Val devuelve un valor numérico hasta el primer símbolo no válido y no lanza un error, lo que puede llevar a una lógica incorrecta.

Dim n = Val("12abc") ' Devolverá 12, aunque la cadena es incorrecta

¿Cuál es la diferencia entre CInt y Integer.Parse?

CInt realiza un redondeo con el redondeo del banquero, mientras que Integer.Parse requiere una coincidencia exacta de la cadena con el número y lanza una excepción en caso de error.

¿Por qué TryParse no siempre devolverá True para la cadena "1,234"?

El resultado depende de la configuración regional de Windows: en algunos lugares el separador decimal es una coma, en otros un punto. Es importante especificar explícitamente el formato:

Dim number As Double
Double.TryParse("1,234", NumberStyles.Any, CultureInfo.InvariantCulture, number)

Errores comunes y anti-patrones

Uso de Val o conversión directa sin verificación
Ignorar la configuración regional
Omitir la verificación de datos recibidos de TextBox o InputBox

Ejemplo de la vida real

Caso negativo

El módulo financiero aceptaba datos a través de InputBox, los convertía mediante Val, y sumas como 10,5 se convertían en 10 en algunos casos (la coma no era reconocida y el punto no fue ingresado).

Pros:

Poco código, parece simple

Contras:

Pérdida de datos, errores en los cálculos

Caso positivo

Transición a TryParse considerando las configuraciones culturales y la validación del campo de entrada.