¿Maneja la excepción una preocupación transversal?

12

No veo mucha diferencia entre las preocupaciones del manejo de excepciones y el registro, ya que ambas son preocupaciones transversales. ¿Qué piensas? ¿No debería manejarse por separado por sí mismo en lugar de intercalado con la lógica central que está implementando un método?

EDIT : lo que estoy tratando de decir es que, en mi opinión, la implementación de un método solo debe contener la lógica para la ruta exitosa de ejecución y las excepciones deben manejarse en otro lugar. No se trata de excepciones marcadas / sin marcar.

Por ejemplo, un idioma podría manejar las excepciones de una forma totalmente controlada mediante el uso de construcciones como esta:

class FileReader {

  public String readFile(String path) {
    // implement the reading logic, avoid exception handling
  }

}

handler FileReader {

   handle String readFile(String path) {
      when (IOException joe) {
        // somehow access the FileInputStram and close it
      }
   }

}

En el lenguaje conceptual anterior, el programa no se compilará en ausencia de FileReader handler , porque el archivo de lectura de FileReader class no está lanzando La excepción. Entonces al declarar el controlador FileReader , el compilador puede asegurarse de que se está manejando y el programa luego se compila.

De esta manera tenemos lo mejor de los problemas de excepción marcados y no comprobados: robustez y legibilidad.

    
pregunta Behrang 09.08.2011 - 06:46

4 respuestas

13

En algunos casos, sí

En los casos en los que tiene una excepción que desea registrar (que supongo que es casi siempre), entonces sí, la excepción está vinculada a una preocupación transversal.

La mayoría de las veces no

Sin embargo, tome la instancia de un SocketListener, si un socketlistener lanza una excepción debido a que el otro extremo interrumpe la conexión, entonces este debe ser un comportamiento anticipado y, por lo tanto, la aplicación debe actuar de acuerdo con las circunstancias que causaron la excepción. Esto no es algo que deba manejar un Aspecto genérico, por lo que no debe ser una preocupación transversal.

Identificar una preocupación transversal

Si está duplicando el mismo código una y otra vez, debe abstraerse. Si la abstracción se promueve a múltiples capas, podría ser una preocupación transversal. Sólo entonces debería ser considerado.

    
respondido por el Justin Shield 09.08.2011 - 08:09
4

El registro es opcional. El manejo de las excepciones no lo es.

El registro es bastante genérico y, aunque proviene de una lógica específica, se alimenta a un consumidor genérico. Las excepciones siempre son específicas de la lógica y algunos códigos que tienen conocimiento de esa lógica deben manejar el desorden que hizo.

Al menos en mi uso limitado de los dos, eso significa que los dos objetivos se manejan mejor de diferentes maneras y no bajo el mismo paraguas de diseño.

    
respondido por el Patrick Hughes 09.08.2011 - 08:01
1

Veo el manejo de excepciones como una preocupación transversal para ciertos tipos de excepciones. Hay excepciones locales que solo el código de llamada inmediata puede manejar correctamente. Un ejemplo podría ser una excepción de la base de datos cuando se intenta ejecutar una consulta. Pero también hay excepciones que pueden y deben manejarse de manera más global. Un ejemplo podría ser una excepción relacionada con la falta de credenciales de seguridad (obliga al usuario a iniciar sesión nuevamente). O al menos necesita un controlador global en caso de que una excepción se deslice a través del código más específico, para explicar al usuario qué debe hacer para reiniciar o enviar un registro a TI o algo por el estilo. Para estos tipos de excepciones manejadas globalmente, es una preocupación transversal.

    
respondido por el RationalGeek 09.08.2011 - 13:50
0

Creo que esto está relacionado con el tema de las abstracciones con fugas.

Muchas excepciones deben ser capturadas y rechazadas a medida que se propagan a través de las capas de abstracción. El relanzamiento debe lanzar la excepción en una nueva forma, apropiada para la abstracción que está realizando el relanzamiento, de modo que tenga sentido como parte de la interfaz. En otras palabras, las excepciones de los niveles más bajos de abstracción deben traducirse a la forma de abstracción actual, de modo que los niveles más altos de abstracción no necesiten conocer los niveles más bajos, ni siquiera para el manejo de excepciones.

Sin embargo, el "principio de abstracciones con fugas" es un problema. Algunas excepciones no se pueden traducir a una forma que tenga sentido dentro de la siguiente capa de abstracción.

Una excepción relacionada con el sistema de archivos en red es un ejemplo simple. Un fallo de red no puede expresarse en términos que tengan sentido para una abstracción de "archivo" o, si lo hace, esa abstracción no ha abstraído completamente todos los detalles relacionados con la implementación del manejo de archivos.

Por lo tanto, una falla en la red se filtraría fuera de la abstracción de la red subyacente y, por lo tanto, debe ser una preocupación transversal en el resto del código.

Sin embargo, esto no es exclusivo de las excepciones. Todos esos códigos de error de valor de retorno para las API de archivos que no están realmente relacionados con la abstracción del archivo, sino que en cambio detallan el disco duro o la red o cualquier otro fallo que sea lo mismo en una forma diferente, lo que implica que los fallos del disco duro y los fallos de la red Las inquietudes transversales, etc., son independientes de cómo se reportan esos fallos.

    
respondido por el Steve314 10.08.2011 - 03:28

Lea otras preguntas en las etiquetas