2008-10-24 20 views

Respuesta

7

captura únicas excepciones que puede manejar. Por ejemplo, cuando se utilizan recursos externos, la mejor práctica es capturar excepciones específicas que usted sabe que puede manejar. En el caso de archivos, esto puede ser (IOException, SecurityException, etc.), en el caso de la base de datos, la excepción puede ser SqlException u otros.

En cualquier caso, no debe quedar atrapado excepciones que no manejan, dejarlas fluir a una capa superior que se pueda. O si por alguna razón detecta excepciones pero no las maneja, vuelva a lanzarlas utilizando solo throw; (que creará una operación de recuperación IL, a diferencia de trow).

En caso de usar recursos que no sabe qué tipo de excepciones pueden arrojar, se verá forzado a captar el tipo de excepción general. Y en este caso lo de las cajas fuertes sería usar dichos recursos de un dominio de aplicación diferente (si es posible), o dejar que la excepción salte al nivel superior (ex UI) donde se pueden mostrar o registrar.

0

Creo que la respuesta absoluta es completamente condicional (cómo control tienes sobre el entorno, cuál es el equilibrio esperado entre rendimiento y coherencia y muchos otros, estoy seguro), pero en general siempre lo hago, eligiendo la seguridad sobre el rendimiento potencialmente más lento.

0

siempre depende de lo que desea lograr. Un servidor que no responde puede ser lo suficientemente grave como para detener todo lo que hace la rutina, y la excepción debe ser lanzada a la persona que llama.

En otros casos, no le importa si no actualizó la base de datos o no. Entonces consumir la excepción está bien.

Obviamente, no desea mostrar el seguimiento de la pila a su usuario final, por lo que deberá buscarlo en algún lugar.

2

Eric Lippert tiene un buen blog sobre esto, here.

No tiene sentido (excepto para "molestar" (ver blog)) atrapar una excepción a menos que pueda hacer algo útil; y en la mayoría de los casos simplemente no puedes, así que déjalo burbujear (tu interfaz de usuario debería obviamente limpiar y mostrar algo).

Puede, sin embargo, tener un "intento/finalmente" para tratar con la gestión de recursos. O incluso más limpio, un bloque "usar" para hacer lo mismo.

3

creo que hay tres razones para tener un bloque catch:

  • Puede manejar la excepción y recuperar (de código de "bajo nivel")
  • ¿Quieres rewrap la excepción (de nuevo, desde "bajo nivel" de código)
  • Estás en la parte superior de la pila, y si bien no se puede recuperar la operación en sí, no desea que toda la aplicación para bajar

Si usted se pega a estos, deberías tener muy fe w atrapar bloques en comparación con los bloques try/finally - y esos bloques try/finally casi siempre solo llaman a Dispose, y por lo tanto se escriben mejor como using declaraciones.

Conclusión: es muy importante tener un bloque finally para liberar recursos, pero los bloques catch suelen ser más raros.

Cuestiones relacionadas