Hay una regla simple: si no sabe cómo manejar una excepción, no la atrape.
Cogerlo y volver a ponerlo nulo o en una lista vacía sería lo peor que puede hacer, ya que será difícil depurar de dónde viene el error, o incluso si se produjo un error. Si haces esto, tendrás desarrolladores tirando de sus pelos.
Coger una excepción y volver a lanzarlo como throw e;
también es malo porque pierde la pila original. Se acepta volver a tirar utilizando throw;
, a veces, si tiene una limpieza especial, debe hacerlo solo si hay un error. Por lo general, este no es el caso. Si tiene que limpiar lo que debe hacerse ya sea que haya o no un error, pertenece a la cláusula finally.
Por lo tanto, en general, a menos que haya algo sensato que pueda hacer para recuperarse del error, simplemente permita que la excepción se propague a la persona que llama. Así es como las excepciones están diseñadas para funcionar.
Hay algunas veces en que es posible que desee capturar una excepción para añadir más información (por ejemplo, para la tala), en cuyo caso debe asegurarse de que se utiliza un InnerException
para evitar perder la información original:
try
{
foo(bar);
}
catch (Exception e)
{
throw new FooException("Foo failed for " + bar.ToString(), e);
}
pero en general es mejor no hacer esto a menos que tenga una muy buena razón. Hacer esto evita que los usuarios capten un tipo específico de excepción: detectarán su excepción y luego deberán activar el tipo de InnerException. No es divertido. Solo deja que la persona que llama vea la excepción original.
Parece que solo debe manejar esta excepción en la capa de presentación. Las excepciones deben ser excepcionales. Solo maneje excepciones si puede seguir una ruta lógica diferente en función de la excepción que se produce. –