Diseño de jerarquía de excepciones

7

En mi empresa estamos creando una aplicación web que contiene varios servicios centrales que diseñamos nosotros mismos y que luego especificamos como interfaces. Es decir. Las interfaces son específicas de la aplicación y luego se implementan con bibliotecas de terceros que podemos cambiar con el tiempo. Cuando se trata de excepciones, me he dado cuenta de que las excepciones lanzadas por nuestros servicios deben ser nuestras propias excepciones específicas de la aplicación en lugar de las excepciones específicas de la implementación.

Ahora, me pregunto cómo deberían estructurarse y relacionarse nuestras excepciones entre sí.

Primero, considere una excepción genérica MyAppException . Esta excepción indica que algo inesperado salió mal y lo mejor que podemos hacer es mostrar un mensaje al usuario que diga que algo salió mal y que estamos trabajando en ello. El error podría ser que la base de datos fallara o algo parecido. Esta excepción sería prácticamente lanzada desde todos los métodos que trabajan con la base de datos.

En segundo lugar, considere una excepción MyAppDuplicateException . Esta excepción indicaría que el usuario intentó guardar algo en la base de datos que ya estaba allí. Aquí, podemos mostrar un mensaje de error mucho más específico y esta excepción solo se produce a partir de los métodos que insertan o actualizan las filas de la base de datos.

La aplicación también puede contener otras excepciones similares a MyAppDuplicateException para otras situaciones de error esperado. Ex MyAppNotFoundException etc ...

Ahora a mis preguntas:

  1. ¿Las otras excepciones deberían extender MyAppException ? Realmente no veo ninguna razón para esto, lo he visto en muchos lugares y me pregunto si hay un propósito para ello. La desventaja de esto, como lo veo, es que una declaración try / catch no necesita preocuparse por la excepción específica en este caso. Simplemente puede capturar la excepción principal y, debido a esto, no es necesario que maneje el error específico, lo que fue más o menos el punto de tener la excepción específica.
  2. Si las otras excepciones no extienden MyAppException , ¿ MyAppException debería ser java.lang.RuntimeException ? Esto no requeriría la ejecución del código para detectarlo, lo que me parece natural ya que el punto de la excepción es decir que sucedió algo desconocido y que no se espera que el código en ejecución pueda manejarlo. El código en el punto de entrada de la solicitud aún podría tener una declaración try / catch que atrape MyAppException y se asegure de que se muestre un mensaje al usuario.

editar No hay duda de si se deben verificar las excepciones específicas como MyAppDuplicateException o no, se debe verificar definitivamente.

    
pregunta Ludwig Magnusson 29.05.2012 - 12:30

2 respuestas

8
  1. A veces desea capturar un tipo específico de excepción (por ejemplo, MyAppDuplicateException ) y otras veces desea capturar una categoría completa de excepciones (por ejemplo, MyAppException ). Al tener MyAppDuplicateException extend MyAppException , le está dando al código de llamada un poco más de flexibilidad en la forma en que trata las diferentes excepciones.
  2. El mejor consejo que he escuchado sobre esto es que en términos generales debe lanzar una excepción comprobada si el método que se llama obedece a su contrato. Es una forma de decir "aquí están las cosas que podrían fallar". Definitivamente haría excepciones MyAppDuplicateException y similares (es decir, no RuntimeException s).

Hay un muy buen artículo aquí que debería ayudarlo a evitar la mayoría de las dificultades comunes.

    
respondido por el vaughandroid 29.05.2012 - 13:34
1
  

Me he dado cuenta de que las excepciones lanzadas por nuestros servicios deberían ser   nuestras propias excepciones específicas de la aplicación en lugar de implementación   excepciones específicas.

¿Con esto se refiere a las excepciones definidas por la implementación de terceros? ¿Correcto?

  

Primero, considere una excepción genérica MyAppException. Esta excepción indica > que algo inesperado salió mal y lo mejor que podemos hacer es > mostrar un mensaje al usuario que diga que algo salió mal y que estamos > trabajando en ello. El error podría ser que la base de datos se bloqueó o algo similar > similair. Esta excepción sería prácticamente lanzada desde todos los métodos que funcionan > con la base de datos.

Si este tipo de excepción representa un error en su programa que no se debe a una entrada incorrecta del usuario, sino a algún problema con su código, en Java debería ser una excepción en tiempo de ejecución.

  

En segundo lugar, considere una excepción MyAppDuplicateException. Esta excepción indicaría > que el usuario intentó guardar algo en la base de datos que ya estaba > Aquí, podemos mostrar un mensaje de error mucho más específico y esta > excepción solo se produce desde los métodos que insertan o actualizan la base de datos > filas.

Esta es una excepción marcada en Java.

  

Si las otras excepciones no extienden MyAppException, ¿debería ser MyAppException > java.lang.RuntimeException?

Sí.

  

Esto no requeriría la ejecución del código para detectarlo, lo que para mí suena natural > ya que el punto de excepción es decir que algo desconocido sucedió y > no se espera que el código en ejecución pueda manejarlo. El código en el punto de entrada > de la solicitud aún podría tener una declaración try / catch que detecte > MyAppException y se asegure de que se muestre un mensaje al usuario.

Sí, eso es correcto.

    
respondido por el user48910 29.05.2012 - 13:50

Lea otras preguntas en las etiquetas