La gestion des exceptions est-elle une préoccupation transversale?

Je ne vois pas beaucoup de différence entre les préoccupations liées à la gestion des exceptions et à la journalisation, car les deux sont des préoccupations transversales. Qu'est-ce que tu penses? Ne devrait-elle pas être gérée séparément séparément plutôt qu'entrelacée avec la logique centrale qu'une méthode met en œuvre?

EDIT : Ce que j'essaie de dire, c'est qu'à mon avis, une implémentation de méthode ne devrait contenir que la logique du chemin d'exécution réussi et les exceptions devraient être gérées ailleurs. Il ne s'agit pas d'exceptions vérifiées / non vérifiées.

Par exemple, un langage peut gérer les exceptions de manière entièrement vérifiée en utilisant des constructions comme celle-ci:

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
      }
   }

}

Dans le langage conceptuel ci-dessus, le programme ne compilera pas en l'absence de FileReader gestionnaire , car le readFile de la FileReader classe ne lève pas l'exception. Ainsi, en déclarant le FileReader gestionnaire , le compilateur peut s'assurer qu'il est géré et le programme compile ensuite.

De cette façon, nous avons le meilleur des problèmes d'exception vérifiés et non vérifiés: robustesse et lisibilité.

Dans certains cas, oui

Dans les cas où vous avez une exception que vous souhaitez enregistrer (ce que je suppose être presque toujours), alors oui, l'exception est liée à une préoccupation transversale.

La plupart du temps, non

Cependant, prenez l'instance d'un SocketListener, si un écouteur de socket lève une exception en raison de la coupure de la connexion par l'autre extrémité, cela doit être un comportement anticipé et l'application doit donc agir en fonction des circonstances qui ont provoqué l'exception. Ce n'est pas quelque chose qu'un aspect générique devrait gérer, et ne devrait donc pas être une préoccupation transversale.

Identifier une préoccupation transversale

Si vous dupliquez le même code encore et encore, il doit être abstrait. Si l'abstraction se propage à plusieurs couches, cela pourrait être une préoccupation transversale. Ce n'est qu'alors qu'il devrait être envisagé.

La journalisation est facultative. La gestion des exceptions ne l'est pas.

La journalisation est assez générique et même si elle provient d'une logique spécifique, elle alimente un consommateur générique. Les exceptions sont toujours spécifiques à la logique et certains codes connaissant cette logique doivent gérer le désordre qu'elle a causé.

Au moins dans mon utilisation limitée des deux, cela signifie que les deux objectifs sont mieux gérés de différentes manières et non sous le même parapluie de conception.

Je considère la gestion des exceptions comme une préoccupation transversale pour certains types d'exceptions. Il existe des exceptions locales que seul le code d'appel immédiat peut gérer correctement. Un exemple peut être une exception de base de données lors de la tentative d'exécution d'une requête. Mais il existe également des exceptions qui peuvent et doivent être gérées de manière plus globale. Un exemple peut être une exception liée au manque d'informations d'identification de sécurité (forcer l'utilisateur à se reconnecter). Ou à tout le moins, vous avez besoin d'un gestionnaire global au cas où une exception glisse dans le code plus spécifique, pour expliquer à l'utilisateur ce qu'il doit faire pour redémarrer ou envoyer un journal au service informatique ou quelque chose comme ça. Pour ces types d'exceptions gérées globalement, il s'agit d'une préoccupation transversale.

Je pense que cela est lié à la question des abstractions qui fuient.

De nombreuses exceptions doivent être interceptées et repoussées lorsqu'elles se propagent à travers les couches d'abstraction. La relance doit lever l'exception sous une nouvelle forme, appropriée à l'abstraction qui fait la relance, afin qu'elle ait un sens dans le cadre de l'interface. En d'autres termes, les exceptions des niveaux d'abstraction inférieurs doivent être traduites sous forme d'abstraction actuelle afin que les niveaux d'abstraction supérieurs n'aient pas besoin de connaître les niveaux inférieurs, même uniquement pour la gestion des exceptions.

Cependant, le "principe des abstractions qui fuient" est un problème. Certaines exceptions ne peuvent pas être traduites en une forme qui a du sens dans la couche d'abstraction suivante.

Une exception liée au système de fichiers en réseau est un exemple simple. Une panne de réseau ne peut pas être exprimée en termes qui ont du sens pour une abstraction de "fichier" ou, si c'est le cas, cette abstraction n'a pas vraiment complètement résumé tous les détails relatifs à la mise en œuvre de la gestion des fichiers.

Une défaillance du réseau s'échapperait donc de l'abstraction du réseau sous-jacent et devrait donc être une préoccupation transversale dans le reste du code.

Ce n'est pas unique aux exceptions, cependant. Tous ces codes d'erreur de valeur de retour pour les API de fichiers qui ne sont pas vraiment liés à l'abstraction du fichier, mais détaillent plutôt le disque dur ou le réseau ou tout autre échec est la même chose sous une forme différente, ce qui implique que les échecs du disque dur et les échecs du réseau etc. sont des préoccupations transversales indépendamment de la façon dont ces échecs sont signalés.