Códigos de error dentro de excepciones vs excepciones jerarquía

Question

¿Cree que está bien usar códigos de error dentro de la excepción para especificar el tipo de error? Por favor, echar un vistazo a este código:

public class MyException extends Exception { 
    public static final String ERROR_CODE_INVALID_NAME = ""; 
    public static final String ERROR_CODE_INVALID_ID = ""; 
    ... 

    private String errorCode; 

    public MyException(String message, String errorCode) { 
     super(message); 
     this.errorCode = errorCode; 
    } 

    public String getErrorCode() { 
     return errorCode; 
    } 
} 

Yo sé que es mejor utilizar enumeración en lugar de cadenas en este ejemplo, pero estoy realmente preocupado por el concepto de códigos de error. ¿Crees que la jerarquía de excepciones sería mejor aquí? No puedo encontrar ninguna fuente autorizada que diga que los códigos de error dentro de la excepción son antipatrón. Thx.

Answer 1

Si desea reaccionar de manera diferente (en el código) dependiendo de qué causó la excepción (ya sea un nombre no válido o una ID no válida), le sugiero que tenga excepciones diferentes.

Si no es así, entonces ni siquiera necesita el método getErrorCode(), puede simplemente agregar el código de error al mensaje de la excepción y la excepción le dará toda la información que necesita para la depuración.

Answer 2

Los códigos de error son útiles cuando

• no se puede mostrar un mensaje de error completo (pantalla lavavajillas)
• el código tiene que ser procesado internamente (algo de lógica se activa si aparece un determinado código o un servidor envía un código de error al cliente mientras el cliente es responsable del mensaje)
• tenemos un gran manual y el usuario puede usar el código para obtener información completa
• El usuario no necesita saber qué sucedió , pero tiene que contactar al vendedor

Por lo tanto, la mayoría de las veces, no veo ningún valor añadido en los códigos de error. Prefiero una jerarquía de excepciones o, al menos, un mensaje de error claro que son realmente útiles cuando se encuentran en un archivo de registro (incluso 2 años después de que el programador abandonó la empresa).

Si tiene requisitos para los códigos de error, la solución no está nada mal. Considerar la recogida de todos códigos de error en un repositorio central (un archivo de propiedades) de modo que usted puede intercambiar el conjunto completo de fácil:

myexception.ERROR_CODE_INVALID_NAME=text or number 
myexception.ERROR_CODE_INVALID_ID=text or number 

Answer 3

En cuanto al rendimiento creando un StackTrace de jerarquía de excepciones complejo es muy costosa tanto desde la memoria y aspectos de tiempo, por lo que si crea una jerarquía de excepción personalizada compleja para algo que puede resolver con 3-4 códigos de error estáticos ... preferiría la opción de código de error. En general, prefiero trabajar con excepciones de Runtime (no marcado en la firma del método), el enfoque defensivo de detectar excepciones comprobadas es poco obsoleto.

Answer 4

Normalmente uso una combinación de ambos.

Necesita categorizar sus excepciones y tomar una decisión de diseño.

Por ejemplo, puede usar parámetros como fuente de excepción, tipo, impacto y manejo para categorizar su excepción. Si las excepciones caen en la misma categoría, use códigos de error dentro. Use la jerarquía para la excepción que cae en diferentes categorías.

Si elige manejo de excepciones es un parámetro importante, puede elegir entre las dos opciones en función de cómo desea manejarlos:

1. códigos Uso de error si se desea capturar todos los tipos en un solo bloque de captura y manejarlos de una manera genérica.
2. Utilice la jerarquía si desea capturar un tipo específico a la vez y trátelos en consecuencia.

Answer 5

Según mi experiencia, los códigos de excepción se utilizan principalmente como mensaje de información para el usuario.

No he visto ni siquiera una vez que alguien intente analizar el mensaje de excepción general para reaccionar de manera diferente depende del código de error, por lo general se hace a través de la jerarquía de excepciones.

Por otra parte, podría ser difícil crear una nueva subclase de excepción para cada caso en particular y luego se usarán códigos de excepción.
Por ejemplo, si para el código de usuario no mide por qué la transacción falló, debería revertirla de cualquier forma, pero para el usuario final es importante por qué sucedió (params incorrectos, conexión a la base de datos u otra).

Por lo tanto, para resumir, si espera diferentes formas de manejar diferentes situaciones, es mejor usar diferentes tipos de excepciones, pero si debe manejar algunos problemas de la misma manera, pero solo notificar al usuario sobre una causa particular, es más fácil use códigos de excepción.