Use excepciones para cosas excepcionales, cosas que razonablemente no puede esperar encontrar con demasiada frecuencia, cosas que indican que algo sale mal. Por ejemplo, si la red está inactiva, es algo excepcional para un servidor web. Si la base de datos no está disponible, significa que algo está mal. Si falta el archivo de configuración, probablemente significa que el usuario lo echó a perder.
No use excepciones para manejar código incorrecto. Para verificar la exactitud del código, debe usar las aserciones o, en .NET Framework 4 y posteriores, los contratos de código (que reemplazan las aserciones y tienen características adicionales, particularmente valiosas).
No use excepciones en casos no excepcionales. El hecho de que el usuario, cuando se le pide que ingrese un número, ingresó "perro" no es tan excepcional como para merecer una excepción.
Tenga cuidado al elegir los tipos de excepciones. Crea tus propios tipos cuando sea necesario. Elija cuidadosamente la herencia, teniendo en cuenta que la captura de los padres también atrapará a los hijos. Nunca throw Exception
.
No use códigos de retorno para errores. Los códigos de error son fácilmente enmascarados, ignorados, olvidados. Si hay un error, puede manejarlo o propagarlo a la pila superior.
En los casos en que se espera que un método devuelva un error y el error no sea excepcional, use enumeraciones, nunca números de error. Ejemplo:
// Note that the operation fails pretty often, since it deals with the servers which are
// frequently unavailable, and the ones which send garbage instead of the actual data.
private LoadOperationResult LoadProductsFromWeb()
{
...
}
El significado de LoadOperationResult.ServerUnavailable
, LoadOperationResult.ParsingError
etc. es mucho más explícito que, digamos, recordar que el código 12 significa que el servidor está inactivo y el código 13, que los datos no se pueden analizar.
Use códigos de error cuando se refieren a los comunes, conocidos por todos los desarrolladores que trabajan en el dominio específico. Por ejemplo, no reinvente un valor de enumeración para HTTP 404 Not Found o HTTP 500 Internal Server Error.
Cuidado con los booleanos. Tarde o temprano, querrá saber no solo si un método específico tuvo éxito o no, sino por qué. Las excepciones y enumeraciones son mucho más poderosas para eso.
No atrape todas las excepciones (a menos que esté en la parte superior de la pila). Si detecta una excepción, debe estar listo para manejarla. Capturar todo muestra que no te importa si tu código se ejecuta correctamente. Esto puede resolver el "No quiero buscar en este momento cómo solucionar esto", pero tarde o temprano le hará daño.
En C #, nunca vuelva a lanzar excepciones como esta:
catch (SomeException ex)
{
...
throw ex;
}
porque estás rompiendo la pila Haz esto en su lugar:
catch (SomeException)
{
...
throw;
}
Haga un esfuerzo al escribir mensajes de excepción. Cuantas veces he visto algo como throw Exception("wrong data")
o throw Exception("shouldn't call this method in this context")
. Otros desarrolladores, incluido usted mismo seis meses después, no tendrían idea de qué datos están mal y por qué o por qué no deberíamos llamar a algún método en un contexto, ni a qué contexto precisamente.
No mostrar mensajes de excepción al usuario. No se esperan para la gente común y, a menudo, incluso son ilegibles para los propios desarrolladores.
No localice mensajes de excepción. Buscar en la documentación un mensaje localizado es agotador e inútil: cada mensaje debe estar en inglés y solo en inglés.
No se centre exclusivamente en excepciones y errores: los registros también son extremadamente importantes.
En .NET, no olvide incluir excepciones en la documentación XML del método:
/// <exception cref="MyException">Description of the exception</exception>
La inclusión de excepciones en la documentación XML facilita mucho las cosas para la persona que usa la biblioteca. No hay nada más molesto que tratar de adivinar qué excepción podría ser lanzada por un método y por qué.
En este sentido¹, el manejo de excepciones de Java proporciona un enfoque más estricto y mejor. Te obliga a lidiar con las excepciones potencialmente lanzadas por los métodos llamados, o declarar en tu propio método que puede arrojar las excepciones que no manejas, haciendo las cosas particularmente transparentes.