Try...Catch

Saludos,

Creo que la pregunta no deberia ir relacionada al hecho del rendimiento,
sino de la funcionalidad.
¿Que haces con esa excepcion?
La muestras al usuario? Haces alguna operacion de mantenimiento de
integridad de la operacion?
o simplemente no haces nada con ella??

Si la respuesta es la ultima, es de mala practica de programacion, "ocultar"
excepciones que no te interesan, pues se podrias provocar que existan
ciertos bugs muy dificiles de rastrear luego (claro, siempre depende de la
complejidad de los sistemas). Es mas, deberias solo atrapar las excepciones
que tu esperan para manejarlas apropiadamente.

Para el resto de excepciones, lo unico que se esperaria es que las atrapes,
realices las acciones que reuqiera tu programa la asegurar la integridad de
los datos y la aplicacion, y volverla a lanzar.

Te pongo un ejemplo, mira el siguiente codigo:

try {
..
..
try {
fecha = DateTime.Parse(cadenaFecha);
}
catch (FormatException) {
fecha = DateTime.Now; // Digamos que tomo un predeterminado
}
..
..
..
}
catch (Exception) {
/// Aca libero recursos, o hago todo lo necesario para asegurar
la estabilidad
/// del sistema operativo, y la integridad de los datos de la
aplicacion

throw;
}



Si no tuviera que realizar ninguna accion en el catch (Exception) final,
pues simplemente omitiria esta accion y dejaria que en caso de una
exception, la misma se propague.


Sobre el rendimiento, no te preocupes por el rendimiento de los bloques try
... catch, en realidad lo que consume recursos muchas veces es la propia
accion de iniciar una excepcion y no el uso de bloques try ... catch ...
indiscriminadamente.

Asi que en resumen, el rendimiento no debe ser tu preocupacion al momento de
establecer bloques estructurados de manejo de errores, sino las buenas
practicas que deberias usar para el diseño de los mismos.



Saludos
Pedro Luna, [MVP VB.NET]
Gye, Ecu