Patrón de manejo de excepciones

Question

Es un patrón común que veo donde los códigos de error asociados con una excepción se almacenan como entradas finales estáticas. cuando se crea la excepción para lanzarse, se construye con uno de estos códigos junto con un mensaje de error. Esto da como resultado el método que va a atraparlo teniendo que mirar el código y luego decidir sobre un curso de acción.

La alternativa parece ser- declarar una clase para cada caso de error de excepción (aunque relacionados excepciones serían derieve de una clase base común)

¿Hay un término medio? ¿Cuál es el método recomendado?

Answer 1

Esta es una buena pregunta. Creo que definitivamente hay un término medio.

Los códigos de error son esenciales en mi opinión para mostrar errores al control de calidad, y para que los clientes informen al servicio de atención al cliente y de nuevo a los desarrolladores.

Para el manejo programático de errores, yo personalmente no recomiendo códigos de error, recomendaría una nueva clase para cada categoría de errores, pero definitivamente no para cada error. Java hizo un trabajo decente para comenzar con Excepciones como IOException, IllegalArgumentException, UnsupportedOperationException, etc. Frecuentemente las lanzo y las capturo cuando sea apropiado en mi código.

Si tiene una nueva categoría de excepciones a las que su código debería responder programáticamente, entonces definitivamente debería crear una nueva clase para ella, ampliando la clase padre correspondiente. Por ejemplo, UserRegistrationException o ProductException.

Answer 2

Si puede generalizar el comportamiento en diferentes casos de error, especialmente si dicho comportamiento se puede clasificar en "clases" de comportamiento (sin juego de palabras), tener una jerarquía de clase de excepción tiene sentido. Si debe detectar TODAS (o casi) excepciones de todos modos, y el manejo de la mayoría de ellas es casi idéntico .

Answer 3

El "terreno intermedio", como yo lo veo, es usar los "códigos de error" internos (patrón común, pero no muy común, IMO) como información adicional para fines informativos/informativos; pero no para decidir quién atrapa la excepción (esto está determinado por la clase de excepción).

Answer 4

Para responder a su pregunta específica: Su decisión debe basarse en cómo y por qué se procesarán sus excepciones. ¿Desea que su programa sea lo más infalible posible y reaccione convenientemente ante todos los posibles escenarios de error de forma individual? Entonces deberías crear una clase Exception para cada posible error que puedas identificar. De lo contrario, es mejor decidir para cada caso individualmente.

Hay un número de errores muy comunes que ponen en peligro la estabilidad de su programa completo (como ClassNotFoundException o NoSuchMethodException); estos definitivamente deben manejarse específicamente. Hay otros errores que están estrechamente relacionados entre sí, lo que da como resultado problemas similares: estos pueden agruparse u organizarse jerárquicamente (IOException representa todo tipo de errores relacionados con la entrada o la salida, NetworkIOException solo se aplica a errores de entrada y salida relacionado con el acceso a la red, etc.).

Mucho más importante que el nombre de la excepción y la jerarquía de clases, en mi opinión, es lo que haces con él: ¿dónde colocas tus bloques try/catch? ¿Qué entradas de registro se deben escribir para qué archivo de registro? ¿Quién debería ser notificado? ¿Qué mensajes de error se deben presentar solo a los administradores/desarrolladores? ¿Qué errores deberían comunicarse al usuario final?

Hay muchos patrones para manejar excepciones, respondiendo todo tipo de preguntas como estas. Se puede encontrar una colección bastante extensa de patrones comunes y útiles here.