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

Muchas gracias,

La verdad que tienes toda la razón en el uso del
Try/Cacth, pero es que pensaba que cuanto más código
estuviera dentro de un Try/Cacth el rendimiento bajaba...

Pero lo realmente importante es la organización del código
para capturar las excepciones y no el tamaño de lo que se
encuentre dentro del Control...

Muchas gracias de nuevo y un saludo...

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


.

Deberias de pensar en la posibilidad de crear una capita que maneje las
excepciones, eso haria mas "limpia" la aplicacion

"" escribió en el mensaje
news:0e6501c4e686$7aa9a1c0$
Muchas gracias,

La verdad que tienes toda la razón en el uso del
Try/Cacth, pero es que pensaba que cuanto más código
estuviera dentro de un Try/Cacth el rendimiento bajaba...

Pero lo realmente importante es la organización del código
para capturar las excepciones y no el tamaño de lo que se
encuentre dentro del Control...

Muchas gracias de nuevo y un saludo...

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


.