try catch Lento

17/09/2004 - 11:03 por Mark Elmer | Informe spam
Hola a todos.
Me he dado cuenta que cuando tu tienes un bloque Try catch
si algo va mal durante el proceso, este se ralentiza
muchisimo pero sólo la primera vez que ocurre.

por ejemplo si tenemos esto:
private void button1_Click(object sender, System.EventArgs
e)
{
object obj="patata";
int n=Convert.ToInt32(obj);
}
Si le damos al boton, la primera vez, el programa se queda
colgado durante aprox un segundo, a la segunda ya ni se
nota.
Alguien ha notado esto? sabeis a que se debe?
Gracias.

Mark Elmer

Preguntas similare

Leer las respuestas

#1 Pedro Luna Montalvo
17/09/2004 - 15:52 | Informe spam
Siempre iniciar una excepcion es un proceso pesado, y deberia ser manejado
con mucho cuidado. Tu mismo acabas de notar el tiempo de demora ocasionado
por el inicio de una excepcion. Si revisas la excepcion, esta almacena gran
informacion de depuracion, como la pila de llamadas, que debe ser generada
al momento del inicio de la mismaesto toma su tiempito ;)

Pedro Luna, MVP
Gye, Ecu


"Mark Elmer" escribió en el mensaje
news:073801c49c95$28592ed0$
Hola a todos.
Me he dado cuenta que cuando tu tienes un bloque Try catch
si algo va mal durante el proceso, este se ralentiza
muchisimo pero sólo la primera vez que ocurre.

por ejemplo si tenemos esto:
private void button1_Click(object sender, System.EventArgs
e)
{
object obj="patata";
int n=Convert.ToInt32(obj);
}
Si le damos al boton, la primera vez, el programa se queda
colgado durante aprox un segundo, a la segunda ya ni se
nota.
Alguien ha notado esto? sabeis a que se debe?
Gracias.

Mark Elmer
#2 Rodrigo Corral [MVP]
17/09/2004 - 18:06 | Informe spam
Yo lo que usaria es el TryParse de la clase Double, asi te evitas tener que
controlar una excepción. Es lo más eficiente, además parece que lo del
TryXXXX para evitar tener que manejar excepciones parece que va a ser el
patrón en el framework 2.0.


Un saludo
Rodrigo Corral González [MVP]

FAQ de microsoft.public.es.vc++
http://rcorral.mvps.org
#3 Octavio Hernandez
17/09/2004 - 23:42 | Informe spam
Buscando con Google sobre este tema me llevó a una interesante discusión
sobre las excepciones entre Miguel de Icaza (Mono) y Brad Adams (.NET CLR)
que recomiendo a todos...

Yo personalmente no me corto al utilizar las excepciones por el hecho de que
puedan ralentizar el programa, le doy más peso a la importancia conceptual y
organizativa que estas ofrecen...

Salu2 - Octavio

"Mark Elmer" escribió en el mensaje
news:073801c49c95$28592ed0$
Hola a todos.
Me he dado cuenta que cuando tu tienes un bloque Try catch
si algo va mal durante el proceso, este se ralentiza
muchisimo pero sólo la primera vez que ocurre.

por ejemplo si tenemos esto:
private void button1_Click(object sender, System.EventArgs
e)
{
object obj="patata";
int n=Convert.ToInt32(obj);
}
Si le damos al boton, la primera vez, el programa se queda
colgado durante aprox un segundo, a la segunda ya ni se
nota.
Alguien ha notado esto? sabeis a que se debe?
Gracias.

Mark Elmer
#4 Leonardo Azpurua
18/09/2004 - 15:08 | Informe spam
"Octavio Hernandez" escribió en el mensaje
news:
Mostrar la cita
que
Mostrar la cita
y
Mostrar la cita
Hola, Octavio:

Sería bueno que incluyeras el vínculo a la discusión (puede ser interesante
leerla).

El control de excepciones es vital. Pero debería combinarse con prácticas
defensivas, es decir: primero nos aseguramos de que todos los requisitos
para la operación que vamos a ejecutar se satisfacen y luego llamamos a la
operación. Una excepción, entonces, debe producirse solo como consecuencia
de una causa imprevista -fallo de hardware, registro eliminado por otro
usuario, bloqueo de un recurso-

Es decir, las excepciones deben usarse para poder detectar condiciones
excepcionales, pero no deberían reemplazar una buena técnica de programación
"defensiva", y deberían dispararse sólo de manera "excepcional".

Salud!

Leonardo
mvp vb
#5 Octavio Hernandez
18/09/2004 - 18:06 | Informe spam
Hola, Leonardo!

a) En el mensaje anterior se me olvidó pegar la URL:

http://blogs.msdn.com/brada/archive...50403.aspx

b)

Mostrar la cita
Y si los requisitos no se satisfacen, ¿qué haces? Para mí lo más adecuado es
precisamente lanzar una excepción específica de nuestra librería/componente,
que quien hace la llamada no deberá ignorar...

Saludos - Octavio

**********************************
"Leonardo Azpurua" <l e o n a r d o (arroba) m v p s (punto) o r g> escribió
en el mensaje news:OoeG5%
Mostrar la cita
CLR)
Mostrar la cita
conceptual
Mostrar la cita
interesante
Mostrar la cita
programación
Mostrar la cita
Ads by Google
Search Busqueda sugerida