¿El manejo de excepciones es una preocupación transversal?

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

EDITAR : 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 el camino exitoso de la ejecución y las excepciones deben manejarse en otro lugar. No se trata de excepciones marcadas / no marcadas.

Por ejemplo, un lenguaje podría manejar excepciones de una manera totalmente verificada 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 del FileReader controlador , porque el archivo readFile de la FileReader clase no arroja la excepción. Entonces, al declarar el FileReader controlador , el compilador puede asegurarse de que se esté manejando y el programa compila.

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

En algunos casos si

En los casos en 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 mayoria del tiempo, no

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

Identificando una preocupación transversal

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

El registro es opcional. Manejar 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 con conocimientos sobre esa lógica tienen que manejar el desorden que generó.

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.

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 al intentar 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 (obligar al usuario a iniciar sesión nuevamente). O, al menos, necesita un controlador global en caso de que una excepción pase por el código más específico, para explicarle al usuario qué debe hacer para reiniciar o enviar un registro a TI o algo así. Para estos tipos de excepciones manejadas globalmente, es una preocupación transversal.

Creo que esto se relaciona con el tema de las abstracciones con fugas.

Se deben atrapar y volver a lanzar muchas excepciones a medida que se propagan a través de las capas de abstracción. El relanzamiento debe arrojar la excepción en una nueva forma, apropiada para la abstracción que está haciendo el relanzamiento, de modo que tenga sentido como parte de la interfaz. En otras palabras, las excepciones de los niveles inferiores de abstracción deben traducirse a la forma de abstracción actual para que los niveles superiores de abstracción no necesiten conocer los niveles inferiores, incluso solo 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. Una falla 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 de la red se escaparía de la abstracción de 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 archivo que no están realmente relacionados con la abstracción del archivo, sino que detallan el disco duro o la red o cualquier falla son lo mismo en una forma diferente, lo que implica que las fallas del disco duro y la red etc. son preocupaciones transversales independientemente de cómo se reportan esas fallas.