Excepciones: uso y abuso de la instrucción try/except

[mamcx]

Y quien GARANTIZA que el problema va a ser porque cbLinea.text <> Integral? Y si se quedo el programa sin memoria? Y si hay un overflow? Y si el numero EFECTIVAMENTE es uin integral pero del tipo BigInt? Y si el usuario escribe 1, luego lo borra y queda en ""?

O sea, si saca el error: Es porque cbLinea.text <> Integral o porque cbLinea.text <> vacio? Como ves, minimamente encontramos 2 estados de (posible) error.

Y como sabe el usuario que es un numero? En ese caso, se debe 1)Poner una mascara 2) Ojala un edit que tenga algo que identifique es un numero, por ejemplo esos que desplegan una calculadora...


En mis años de programador he visto que errores IMPOSIBLEs pasan.... las correcciones deben hacerse con bisturi, no con espada, porque cuando se va acumulando codigo asi, se complica la cosa....

Ahora analiza la opcion desde el punto de vista del usuario.... que GARANTIZA que va a saber que hacer? Si no saca un mensje, lo mas seguro es que se puede suponer, el campo es opcional, no obligatorio.

Ahora si lo que quieres es eludir el molesto mensaje de error, hay muchas maneras:

1- Un beep

2- Poner un muñequito o asterisco rojo al lado del control, indicando que paso/que hacer

3- Flashear el control

4- Cambiar el mensaje de Excepcion por un messageboc informativo "Hey chico, es un numero, Ok?"

5- Construir el control para que definitiva y absolutamente, no pueda meter un numero NO integral

Y esas si son soluciones. De lo contrario, llamara el usuario a preguntar que es lo que pasa o se quedara dando vueltas al asunto adivinando el comportamiento oculto del sistema....