Exceptions à l'action

Précédent 1 2 3 4 Page 3 Suivant Page 3 sur 4

Exemple de jeu d'exceptions

Dans la figure 1, vous voyez quatre types d'exceptions conçues pour effectuer quatre types d'actions, comme suit:

  1. BusinessException : une condition exceptionnelle s'est produite. Cette condition a été prévue et peut être vérifiée par la méthode appelante pour une action immédiate.
  2. ParameterException : les données saisies ne permettent pas un traitement correct. L'utilisateur doit être invité à ressaisir des données valides ou à modifier les conditions dans lesquelles le traitement a lieu.
  3. TechnicalException : un problème technique tel qu'une instruction SQL non valide s'est produit. L'opération demandée ne peut pas être exécutée. L'utilisateur doit contacter le service d'assistance pour enquête ou essayer un autre service. L'utilisation de l'application par d'autres utilisateurs n'est pas impactée.
  4. CriticalTechnicalException : un problème technique tel qu'une panne de base de données s'est produit. Dans ces conditions, l'ensemble de l'application est inutilisable. L'utilisateur doit être encouragé à réessayer plus tard. Les autres utilisateurs ne doivent pas utiliser l'application tant qu'elle n'a pas été réparée.

Cet ensemble d'exceptions n'est qu'un exemple; de nombreux autres ensembles d'exceptions pourraient être définis de la même manière. Par exemple, TechnicalExceptionet CriticalTechnicalExceptionpourrait être conçu comme une classe d'exception unique avec un severityattribut booléen . L'important est de se concentrer sur le type d'action à entreprendre plutôt que sur la question qui a soulevé l'exception.

Journalisation des exceptions

Bien que la sémantique des exceptions se concentre sur l'action à entreprendre, le problème qui a été soulevé est également important. L'équipe de développement pourrait, par exemple, utiliser ces informations pour déboguer le code. Dans ma conception d'exception, des informations sur la cause de l'exception peuvent être trouvées dans le fichier journal des erreurs de l'application. Avec un bon cadre de journalisation en place, il devrait être suffisant de consigner les informations sur le problème à partir du message d'exception et de la trace de la pile.

Le seul problème qui reste dans la façon de concevoir l'exception afin que ces informations puissent être facilement récupérées. Une solution consiste à fournir à l'exception un attribut id représentant le type de problème en question. En outre, si le problème a levé sa propre exception, cette exception peut être imbriquée dans l'exception d'application. Au moment de la capture, le message d'origine et la trace de la pile peuvent être récupérés à partir de l'exception imbriquée. L' attribut id et l'imbrication d'exceptions sont deux façons d'inclure des informations relatives au problème dans l'exception elle-même.

Concevoir le flux d'exceptions

Une fois que vous avez conçu les exceptions elles-mêmes, l'étape suivante consiste à réfléchir à la manière dont elles se dérouleront dans votre application. Une architecture d'application JEE standard est principalement composée de quatre packages: présentation, activité, intégration et persistance. Les exceptions sont généralement levées par les packages d'intégration et de persistance. Dans le business package, les couches d'exécution internes interceptent les exceptions vérifiées dès que possible, tandis que les couches externes capturent les exceptions d'exécution et prennent les mesures appropriées en fonction de leur classe. Vous pouvez également lancer et intercepter certaines exceptions vérifiées dans le package métier. Dans ce schéma, la responsabilité des packages d'intégration et de persistance, ainsi que de la couche interne du package métier, est de convertir les exceptions d'exécution en actions.Une architecture d'application JEE typique de ce type est illustrée à la figure 2.

Le chemin d'une exception levée à partir du package de persistance (par exemple) dépend de l'endroit où le problème peut être résolu. Si la méthode appelante peut résoudre le problème, l'exception est immédiatement interceptée, l'action appropriée est prise et l'activité se déroule normalement. Si le problème ne peut pas être résolu, l'exception est imbriquée dans une exception d'exécution et transmise silencieusement via les couches intermédiaires du Business Package aux couches supérieures de l'application. Dans ces couches, généralement par un type de contrôleur d'application, l'exception d'exécution est interceptée, l'action appropriée est prise et la couche de présentation affiche le message d'erreur correspondant à l'utilisateur. La capture immédiate des exceptions vérifiées et la capture tardive des exceptions d'exécution sont les deux principaux scénarios de ce type de conception d'exceptions, comme le montre la figure 3.