Visual CSharp .NET - Para que sirve el finally del try...

Saludos...

Es una pregunta por aficionado y curiosidad... Para que sirve el finally del bloque try para capturar errores... Yo se que el finally se corre ya sea que el bloque no haya errores, o si los haya... Pero eso no es lo mismo que poner el codigo que sigue en el programa fuera del try???...

Para explicarme mejor, escribiré un ejemplo, sobre una coneccion a una base de datos...

Tengo este codigo para conectarme con la base de datos...

try
{
Coneccion.Open();
}
catch (Exception)
{
MessageBox.Show("La coneccion fallo");
}
finally
{
Coneccion.Close();
}

Esto seria lo mismo que poner el siguiente codigo... no?...

try
{
Coneccion.Open();
}
catch (Exception)
{
MessageBox.Show("La coneccion fallo");
}
Coneccion.Close();

Me parece que en los dos casos, ocurririra lo mismo... Haber si alguien me puede responder... Si es que finally posee una funcionalidad mas compleja... o yo peco de ignorante :-)...

Saludos y Gracias...

Hola:

No estoy seguro si es que ocurriría lo mismo en ambos casos, pero eso lo puedes comprobar facilmente, cometiendo un error a proposito, se me ocurre por ejemplo, equivocate en el nombre de la base de datos en la cadena de conexión y prueba ambos codigos, ahi podrías ver si es que ocurre lo mismo.

En lo que si te puedo aportar es en lo siguiente:

- En el codigo que tienes la conexión no se cierra hasta despues de aceptar el messagebox (imagina que no le das clic al aceptar del messagebox queda la conexión abierta por mucho rato), razón por la cual yo cambiaría el codigo de la siguiente manera y además usaría la primera opción de codigo:

int errores = 0;
try
{
Coneccion.Open();
}
catch (Exception)
{
errores++;
}
finally
{
if (Connection.State == ConnectionState.Open)
{
Coneccion.Close();
}
if (errores > 0)
{
MessageBox.Show("La coneccion fallo");
}
}

Con este codigo si hay un error en el catch la variable errores se transforma en 1 (de no haber error la variable errores se mantiene en cero), para despues verificarlo en el finally, donde primero cerramos la conexión
solo si es que esta fue abierta (podrian haber casos en los cuales no se abra) y despues ya teniendo la conexion cerrada mostramos el mensaje solo si es que la variable errores es igual a 1, de lo contrario no muestra mensaje .


Saludos
Alex A. Salamanca E.
Ingeniero (e) Computación e Informática
Chile.

Saludos...

Mil gracias por responder, pero aun asi me he quedado con la duda... :-)... Es que por ahi me hicieron la nota de que el finally puede tener implementaciones mas complejas... Porque si hace lo mismo tenga o no tenga el finally... Asi que el que sepa algo avisa... Aun asi un agradecimiento a Alex, por el tiempo y la atencion...

Que tal, pues las dos se pueden ejecutar pero vayamos por partes
Primero aun Try siempre lo acompania una Catch.
Try
{//ejecuta el siguiente codigo
funcionx;
}
catch
{
//si se produce un error esta parte se ejecuta
//en caso negativo esta funcion esto no se ejecuta
}
Finally
{
//ocurra o no ocurra error ejecuta el siguiente codigo
//por ejemplo cierra todas las conexiones abiertas.
}

Nota: Finally puede o no puede implementarse. Pero en caso
de implementarse siempre se ejecuta.

saludos.

Saludos...

Creo que no has comprendido mi duda miguel... Conozco el funcionamiento del bloque try...Lo que pasa es que tengo un dilema, porque no veo la funcionalidad real.. Porque igual, el codigo que corro en el "finally", puedo ponerlo como si fuera codigo normal, y no necesariamente dentro del bloque try... asi como lo puse en el primer ejemplo... Puedo escribir try, su respectivo catch, y no utilizar finally, y simplemente el codigo que sigue ponerlo como si fuera codigo que no tiene relacionado nada con el bloque try... Espero haberme explicado...

Pues entendi tu duda pero aun no te queda claro el funcionamiento,
si ocurre un error de la manera en como esta tu codigo, de inmediato
se pasaria al bloque catch pero no pasarias a cerrar la conexion,
facilmente puedes comprobarlo si cambias los parametros en la
cadena de conexion; y ejecutas el codigo.


Suerte.

Saludos.

la duda del compañero y tmbien la mia.... es que perdon por la expresion... es que finally se ejecuta a huevo osea siempre... hagas lo que hagas entre a un catch o no...por tal motivo entonces no tiene razon de ser por que podria ponerse el codigo despues del try y se ejecutara.... sin embargo creo que la cosa podria ir por aca estimado.... me supongo que pueden existir excepciones que aborten la ejecucion normal del programa y el codigo no siga su flujo....y puede que finally si alcanze a ejecutar algo como un respaldo o guardar un archivo que seria muy critico o cerrar una base de datos yo que se....... seria mi unica explicacion por que fuera de eso no le veo nada, siempre se ejecuta....., ...

y a mi me surgio la misma duda y por eso ando hasta aca.... y de hecho yo tengo otra duda... estoy leyendo el tema en un libro y se llama try anidados.... no le veo funcionalidad, sobre todo considerando que una excepcion es eso una excepcion y siempre sucede una a la vez.... entonces para que anidarlo??.....por que yo veo que lo puedo implementar con 2 try independiences en vez de dos anidados... existe alguna ventaja acaso?? penalizacion de rendimiento?? yo no le veo caso...

les dejo mi correo para alguna posible respuesta [email protected]

gracias...

Hola a todos,

Intentaré contestar la pregunta de forma concreta que creo que es lo que falta en este hilo.

El comportamiento de poner o no Finally es el mismo. Por lo tanto es lo mismo ponerlo que no ponerlo. Queda mejor, más elegante, más claro, pero técnicamente no aporta nada. De hecho en C++ (el único estándar abierto de lenguaje orientado a objetos) creo que esta palabra ni existe.

Si se produce una expepción en el try se saltará al catch y después se saltará a las siguientes líneas haya o no finally. De hecho si en el catch se produce excepción (a veces tratando una excepción puede producirse otra) no se ejecutarán las líneas que siguen al bloque catch (estén dentro de finally o no). Si dentro del finally se produce una excepción (pej al cerrar la conexión tenemos un problema con un recurso de IO) no se ejecutarán las líneas que vayan detrás de la que ha lanzado la excepción, aunque todas estén dentro de un bloque finally.

Lo que no es lo mismo es anidar bloques try/catch. Según en qué casos, si tienes excepciones más concretas que quieras tratar, puede interesarte dentro de un bloque try meter otro. En caso de tener una excepción en un segundo nivel (segundo try), la ejecución del primer bloque try no se vería alterada. E Incluso, para evitar situaciones como la que he comentado más arriba, puedes tener la necesidad de poner un try dentro de un catch, porque tratando una excepción pueden producirse otras. Es poco habitual, pero implementable y posible.

Saludos, Mark

Pues yo creo que la principal diferencia entre usarlo y no usarlo es la siguiente:
Si en el bloque "try" existe una sentencia "return", las instrucciones del "finally" también se ejecutan antes que el "return".
Este comportamiento del "finally" a mi particularmente me acojona y no me gusta, pues me gusta que cuando yo diga "return" sea return de verdad, pero es lo que hay.

Salu2.

public class PruebaFinally
{
public static void main(String[] args)
{
System.out.println ("Inicio");
System.out.println (funcion());
System.out.println ("Fin");
}

public static int funcion()
{
int valor;
try
{
valor= 3;
return valor;
}
catch (Exception e)
{
System.out.println ("Capturada");
}
finally
{
valor= 4;
return valor;
}
}
}

En C# no se puede poner un return dentro de un bloque finally, yo me refería a este lenguaje.

El compilador de C# te dará el siguiente mensaje de error: El control no puede salir del texto de una cláusula finally

Por lo que veo, tu código está escrito en java con lo que el comportamiento del finally es distinto. En tal caso, para conseguir un comportamiento más predecible, bastaría con poner el return fuera de un bloque try.

La verdad es que en una función más compleja, con un return dentro de un try y un bloque finally, puede que cueste más de interpretar su ejecución por una persona. Eso implica que puede dificultar mucho la búsqueda de un error en tiempo de ejecución, sobre todo si quién tiene que hacerlo no es quién ha escrito el código. Por mucho que se sepa del lenguaje, por muy buen programador que uno sea, leer e interpretar la ejecución de un código escrito por otro siempre es complejo. Por lo que cuánto más fácil y simple sea lo que programemos mejor será para quién venga detrás.

Así pues, y en mi opinión, evitaría escribir una función evitando returns dentro de bloques try junto con finallys que hacen cosas complejas. Eso siempre que sea posible, aunque seguro que en el 90% de los casos seguro que puede evitarse. De hecho, y es una opinión personal, no solo estoy de acuerdo contigo en que es un poco liado que un return no sea de verdad, si no que creo que las funciones programadas de forma "elegante" tienen su return al final de todo.