try form example ejemplo custom catch c# try-catch try-catch-finally

c# - form - ¿Es una mala práctica regresar desde dentro de un bloque try catch finally?



try catch c# windows form example (7)

El finalmente se ejecutará sin importar qué, así que no importa.

Así que me encontré con un código esta mañana que se veía así:

try { x = SomeThingDangerous(); return x; } catch (Exception ex) { throw new DangerousException(ex); } finally { CleanUpDangerousStuff(); }

Ahora este código compila bien y funciona como debería, pero simplemente no se siente bien regresar desde dentro de un bloque de prueba, especialmente si hay un asociado finalmente.

Mi problema principal es ¿qué pasa si finalmente arroja una excepción de sí mismo? Usted tiene una variable devuelta pero también una excepción que tratar ... entonces, ¿me interesa saber qué piensan los demás acerca de regresar desde dentro de un bloque de prueba?


En su ejemplo, de cualquier manera es equivalente, ni siquiera me sorprendería si el compilador generara el mismo código. Si ocurre una excepción en el bloque finally, tiene los mismos problemas si coloca la declaración return en bloque o fuera de ella.

La verdadera pregunta es estilísticamente, cuál es la mejor. Me gusta escribir mis métodos para que solo haya una declaración de devolución, de esta manera es más fácil ver el flujo fuera del método, se deduce que también me gusta poner la declaración de devolución al final para que sea fácil ver que es el final del método y esto es lo que devuelve.

Creo que con la declaración de devolución tan cuidadosamente colocada como la última declaración, es menos probable que otros vengan y salpiquen declaraciones de devoluciones múltiples en otras partes del método.


Esto puede responder su pregunta

Lo que realmente sucede en una prueba {return x; } finalmente {x = null; } declaración?

Al leer esa pregunta, parece que puede tener otra estructura de captura de prueba en la declaración final si cree que podría arrojar una excepción. El compilador calculará cuándo devolver el valor.

Dicho esto, podría ser mejor reestructurar tu código de todos modos para que no te confunda más tarde o para que alguien más no se dé cuenta de esto también.


Funcionalmente no hay diferencia.

Sin embargo, hay una razón para no hacer esto. Los métodos más largos con varios puntos de salida a menudo son más difíciles de leer y analizar. Pero esa objeción tiene más que ver con los enunciados de devolución que con los bloques catch y finally.


No, no es una mala práctica. Poner el return donde tenga sentido mejora la legibilidad y el mantenimiento y hace que su código sea más simple de entender. No debería preocuparse ya que finally se ejecutará el bloqueo si se encuentra una declaración de return .


Personalmente, evitaría este tipo de codificación ya que no tengo ganas de ver declaraciones de devolución antes de las declaraciones finales.

Mi mente es simple y procesa las cosas de forma bastante lineal. Por lo tanto, cuando paso por el código para el funcionamiento en seco, tendré tendencia a pensar que una vez que puedo alcanzar el enunciado de devolución, todo lo que sigue no importa, lo que obviamente es bastante incorrecto en este caso (no es que afecte el enunciado de devolución sino cuáles podrían ser los efectos secundarios).

Por lo tanto, organizaría el código para que la declaración de retorno siempre aparezca después de las declaraciones finally.


Ver esto también https://.com/a/421827/344822 . Aquí, la respuesta de jon skeet no solo aclara su duda, también le da más información.