¿Cuando usar Try.. Catch ?

3,154 views
Skip to first unread message

Fox Learner

unread,
Jul 23, 2012, 12:10:00 PM7/23/12
to publice...@googlegroups.com
Nos dice el profe de C# que la estructura Try Catch no se debe usar tanto, sino que lo mejor es corregir los errores de código.

Entendí que ese Try enmascara los errores "engañando", por decirlo así, al compilador, pero el error subsiste.

¿Es la misma situación en Visual Foxpro?...

¿Cuando sería recomendable usar Try Catch y cuando no ?..

¿O mas bien, cuando suelen usarlo en la práctica?..

Gracias anticipadas!

Luis Maria Guayan

unread,
Jul 23, 2012, 12:22:59 PM7/23/12
to publice...@googlegroups.com
Utilizar una estructura de control de errores para controlar errores de código, me parece absurdo. Los errores de código se corrigen compilando y probando la aplicación.

TRY .. CATCH (o cualquier control de errores) se utiliza para otro tipo de errores, como errores de escritura/lectura, errores de conectividad, errores que suceden por causas ajenas al desarrollo.

Luis María Guayán
Tucumán, Argentina
_________________________
http://www.PortalFox.com
Nada corre como un zorro
_________________________

--
 
 
 

Pablo Daniel Lissa

unread,
Jul 23, 2012, 12:36:35 PM7/23/12
to publice...@googlegroups.com
Hay veces que sí, conviene minimizar los errores. Por ejemplo:

PROCEDURE esIgual(cParametro)
    LOCAL lRetorno as Logical
    lRetorno = .F.
    TRY
        lRetorno = cParametro == "Hola Mundo"
    CATCH
        MESSAGEBOX("El parámetro debe ser caracter", 16, "Error")
    ENDTRY
ENDPROC

En el fragmento anterior, si intento ejecutar negligentemente esIgual(1986) o esIgual(.T.), ocurriría la excepción. Ese código podría "evitarse" de la siguiente forma:
PROCEDURE esIgual(cParametro)
    RETURN TRANSFORM(cParametro) == "Hola Mundo"
ENDPROC

Con TRANSFORM aseguramos que el valor que comparamos es caracter, y no hace falta TRY - CATCH para los imprevistos.

Esta minimización de riesgos no siempre es posibles. Cuando se sospecha que puede ocurrir un imprevisto, es ahí donde conviene utilizar control de excepciones. Típicos casos son: el acceso a datos, las operaciones de lectura/escritura, la implementación de una librería externa...

Es decir, TRY - CATCH no debe ser utilizado para control de errores, sino para control de excepciones (aspectos imprevistos e inusuales para el circuito tradicional del ejecutable).

leonardo trujillo

unread,
Jul 23, 2012, 1:01:15 PM7/23/12
to publice...@googlegroups.com
try y catch se usa para "capturar excepciones", esto es: ponés entre try y catch código que potencialmente te puede lanzar un error. Por ejemplo, en java (para C# es similar, por supuesto) lo uso por ejemplo para una conexión a base de datos, porque puede ser que la base de datos a la que quiero acceder no esté en ese momento habilitada, entonces hago algo así:

try{
//codigo suseptibles a error
}catch(Exception ex){
//codigo cuando se produce error
elLogDelError(ex);
}

se puede recurrir al manejo de excepciones para no tener que andar controlando por código las cosas que te dan error, por ejemplo podés querer controlar que un usuario ingrese valores en determinado formato, si es un formato no admitido dejás manejás la excepción mandándole un mensaje.
El siguiente es un ejemplo de los tantos que encontrás en java (por ejemplo):
public class ExcepcionApp {
    public static void main(String[] args) {
        String str1="12";
	String str2="0";
        String respuesta;
	int numerador, denominador, cociente;
        try{
            numerador=Integer.parseInt(str1);
            denominador=Integer.parseInt(str2);
            cociente=numerador/denominador;
            respuesta=String.valueOf(cociente);
        }catch(NumberFormatException ex){
            respuesta="Se han introducido caracteres no numéricos";
        }catch(ArithmeticException ex){
            respuesta="División entre cero";
        }
        System.out.println(respuesta);
    }
}
Tal vez por código podrías controlar la entrada de numerador o denominador, del ejemplo, para evitar se produzca el error, pero, como en el ejemplo, controlás el error cuando se dispara, cuando se ingresa alguno de los valores no numéricos.

Ahora ¿en Fox? Creo que se usa a partir de VFP 8:
Te recomiendo el siguiente artículo del Maestro Luis María, que lo explica como nos tiene acostumbrados:
http://www.portalfox.com/index.php?name=News&file=article&sid=579&mode=nested&order=0&thold=0

No creo que Luis María se haya olvidado del artículo y se deba la omisión a su humildad característica

pd: Luis María, me tomo el atrevimiento de hablar de ud como si lo conociera, ya que era seguidor suyo y "alumno" de foro hace algunos años. Saludos

--
 
 
 

Fox Learner

unread,
Jul 23, 2012, 1:22:21 PM7/23/12
to publice...@googlegroups.com
Creo que lo que menciona este enlace sobre VB.NET:

http://msdn.microsoft.com/es-es/library/5hsw66as.aspx

"Siempre que sea posible, sugerimos que utilice el control de excepciones estructurado en el código, en lugar de recurrir al control no estructurado de excepciones y la instrucción On Error."

quizás sea válido tambien en Visual Foxpro.

Pero noto que tanto en C# como en VB.NET esas "excepciones" podrían abundar, es decir, noto cierta vulnerabilidad al teclear código que harían que ante una minima excepcion, el sistema sea parado y se congele, a menos que se haya establecido una rutina de control de errores estructurado/ no estructurado.

En fin, con el comentario del maestro Luis María, entiendo que la estructura Try Catch, no debe usarse en Visual Foxpro, salvo para el control de errores de sistema. Todo lo demás deberá ser corregido, en lo posible, como debe ser, con buenas técnicas de programación.

En el .net, creo que la cosa va por otro rumbo..

Luis Maria Guayan

unread,
Jul 23, 2012, 2:33:02 PM7/23/12
to publice...@googlegroups.com
El 23/07/2012 14:01, leonardo trujillo escribió:
No creo que Luis María se haya olvidado del artículo

La verdad que no lo recordaba :-)

El artículo es de hace 10 años, noviembre de 2002, un mes después de que Ken Levy presentara oficial y públicamente la versión
Beta de VFP8 en DevCon 2002.
Reply all
Reply to author
Forward
0 new messages