Manejo de excepciones generales en C#

Question

Estoy ejecutando un código a través de FxCop y actualmente estoy buscando eliminar todas las infracciones sin interrupción.

El código en sí tiene algunas instancias de bloques de prueba/captura que solo captan excepciones generales;

try 
{ 
    // Some code in here that could throw an exception 
} 
catch(Exception ex) 
{ 
    // Exception Thrown ... sort it out! 
} 

Ahora todos sabemos que esto es una mala práctica, pero pensé que sabía cómo hacerlo correctamente - pero FxCop tiene otras ideas!

Supongamos que el código en el bloque try podría arrojar una excepción IO, y solo una excepción IO. No debe haber nada malo en hacer esto:

try 
{ 
    // Code in here that can only throw an IOException 
} 
catch (System.IO.IOException ioExp) 
{ 
    // Handle the IO exception or throw it 
} 
catch (System.Exception ex) 
{ 
    // Catch otherwise unhandled exception 
} 

Pero FxCop no está de acuerdo conmigo ... Todavía banderas esto como una violación porque yo estoy poniendo System.Exception.

¿Es realmente una mala práctica o debería/puedo ignorar esta violación?

Answer 1

Estoy de acuerdo con FxCop y la mayoría de las otras respuestas aquí: no debe quedar atrapado System.Exception jamás, a menos que sea al más alto nivel en su aplicación para conectarse inesperados (y por lo tanto fatales) excepciones y luego bombardear la aplicación. Also check out this question that's basically about the same thing.

Algunas otras excepciones válidas podrían ser:

• capturar excepciones por la única razón de Regeneración de uno más descriptivo.
• Código de prueba de unidad que necesita algo más complejo que ExpectedExceptionAttribute.
• En el código de biblioteca de fachada que solo existe para proteger a las personas que llaman de las complejidades de llamar a un servicio externo (web), aunque nunca falla realmente, sin importar qué tan grave sea el sistema externo.

Answer 2

Si está escribiendo library (framework), entonces FxCop es 100% correcto.

Capturas excepciones - ¿Qué significa? que sabes por qué arrojaron. ¿Estás seguro de que sabes todas las razones posibles?

Si escribe solo la aplicación, es posible que haya variaciones. Por ejemplo, si captura todas las excepciones no controladas para el registro.

Answer 3

¿Qué dice FxCopy sobre la infracción específica? Si solo desea registrar información sobre una excepción, vuelva a lanzarla, esto es perfectamente válido, aunque hay otras maneras en que esto podría hacerse. Si se vuelven a levantar él sin embargo, asegúrese de que sólo tiene que utilizar:

throw; 

y no

throw ex; 

Tal vez esa es la cuestión?

Answer 4

Si el código en el bloque solo debe arrojar una IOException, entonces ¿por qué quiere atrapar System.Exception también?

Luego, el grado de conformidad con las pautas FxCop que desea lograr es una elección suya. No vería nada malo en capturar cada excepción en el nivel más alto posible y registrar toda la información que pueda, por ejemplo.

Answer 5

Solo debe detectar las excepciones que puede hacer algo al respecto. De lo contrario, permita que la excepción se propague a la persona que llama o, por ejemplo, en una aplicación Gui, las excepciones deben ser manejadas por un controlador genérico catch all y luego registradas. Ver: UnhandledException Así que no te sorprendas a menos que tengas la intención de hacer algo con eso ... admitidamente eso podría simplemente estar registrando el error.

Editar También se fijan en Application.ThreadException

Answer 6

Se supone que tragar excepciones que sabe cómo manejar. Capturar la excepción y no arrojarla (ya sea directamente o envuelto en una excepción específica) significa que conoce los detalles de la excepción en el contexto de la aplicación. Como Exception puede ser cualquier cosa, es poco probable que sepa cómo manejarla.

Si solo está registrando la excepción, no es gran cosa, simplemente conéctela y tírela a una capa externa para manipularla o atraparla.

Answer 7

gris área ...

En un mundo ideal vosotros todos los días cogería una excepción explícita, ya que, en teoría, esos son la única clase que puede hacer frente con sensatez - todo lo demás debe filtrarse a través de la parte superior a un cierto nivel entrenador de animales.

El problema es que no necesariamente vivimos en un mundo ideal y es posible que deseemos usar un controlador genérico para acumular información adicional sobre la excepción genérica (parámetros, etc.) en la excepción y/o realizar registros adicionales antes de aprobar la excepción respalda el árbol y, en cualquier caso, en el nivel apropiado, para organizar las cosas de forma tal que nuestros usuarios finales no vean excepciones en la interfaz de usuario. El contador de esto sería sugerir que cuando se producen nuevos errores a un nivel bajo (en lugar de llegar a su manejador de nivel de aplicación) luego se agrega un manejo específico de la excepción que puede hacer su captura por usted, pero puede haber problemas de implementación con esto. una solución donde se incluye un caso genérico en bits de código que, por cualquier razón, son un poco más propensos a las excepciones no controladas que a uno le pueden gustar.

Si fuera yo probablemente estaría considerando la bandera en una asamblea de base de montaje ...

P. S. Supongo que en ningún momento tiene un controlador que se traga la excepción y permite que la aplicación continúe.

Answer 8

Estoy de acuerdo con las otras respuestas que catch (Exception ex) está bien si bien

1. sólo tiene que entrar y volver a lanzar la excepción o
2. haces al más alto nivel (UI) de su aplicación.

Hay otra situación que viene a la mente en el que podría tener sentido: Al escribir código sin interacción (por ejemplo, algunos servicios del sistema), puede tener sentido perfecto para mantener el programa que se ejecuta si algunos (bienestar definida) la subtarea falla por la razón que sea. Por supuesto, se debe tener cuidado para asegurar que la razón del problema se registre y (tal vez) la tarea se intente de nuevo después de un tiempo.