¿Siempre intentas atrapar llamadas de recursos externos?

Question

¿Debería siempre ajustar las llamadas de recursos externos en un try-catch? (es decir, llamadas a una base de datos o sistema de archivos) ¿Existe una mejor práctica para el manejo de errores al llamar a recursos externos?

Answer 1

Capture solo las excepciones que puede manejar . Así, por ejemplo, cuando se usan recursos externos, la mejor práctica es detectar excepciones específicas que sepa que puede manejar. En el caso de archivos, puede ser (IOException, SecurityException, etc.), en el caso de Database, la excepción puede ser SqlException u otros.

En cualquier caso, no capturar las excepciones que no maneja , déjalos fluir a una capa superior que pueda. O si, por algún motivo, captura excepciones pero no las maneja, vuelva a lanzarlas utilizando solo lanzar; (lo que creará una operación IL de reedición, en oposición a la trow).

En el caso de usar recursos que no sabes qué tipo de excepciones pueden generar, estás obligado a capturar el tipo de excepción general. Y en este caso, lo más seguro sería usar dichos recursos de un dominio de aplicación diferente (si es posible), o dejar que la excepción suba hasta el nivel superior (ex UI) donde se pueden mostrar o registrar.

Answer 2

Creo que hay tres razones para tener un bloqueo:

• Puede manejar la excepción y recuperarse (del código de "nivel bajo")
• Desea volver a envolver la excepción (de nuevo, desde " código de nivel bajo '')
• Estás en la parte superior de la pila y, si bien no puedes recuperar la operación en sí, no quieres que se caiga toda la aplicación

Si te limitas a estos, deberías tener muy pocos bloques catch en comparación con los bloques try / finally , y esos bloques try / finally casi siempre están llamando a Desechar , y por lo tanto mejor escrito como usando declaraciones.

Línea inferior: es muy importante tener un bloque finally para liberar recursos, pero los bloques catch generalmente deben ser más raros.

Answer 3

> Sepa cuándo configurar un bloque try / catch. Por ejemplo, puede verificar mediante programación una condición que pueda ocurrir sin utilizar el manejo de excepciones. En otras situaciones, es apropiado utilizar el manejo de excepciones para detectar una condición de error.

Eso es lo que encontré y tiene sentido para mí ... Verifique manualmente las cosas obvias, deje que try-catch haga el resto ...

Answer 4

Eric Lippert tiene un buen blog sobre esto, aquí .

No tiene sentido (a excepción de " irritante " (ver blog)) capturar 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 caer (tu IU obviamente debería limpiar y mostrar algo).

Sin embargo, podría tener un " probar / finalmente " para hacer frente a la gestión de recursos. O incluso más limpio, un " utilizando " bloque para hacer lo mismo.

Answer 5

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

Answer 6

siempre depende de lo que quieras lograr. Un servidor que no responde puede ser lo suficientemente serio como para detener todo lo que está haciendo 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á capturarlo en algún lugar.