Je sais que c'est cher mais (OMI) je pense que c'est une très bonne pratique. Je parle de règles comme, par exemple, vous ne pouvez pas enregistrer une facture si vous n'êtes pas un vendeur ... donc dans ce cas, lever une exception disant `` vous n'êtes pas autorisé '' ou autre ...
Une autre approche serait d'avoir des objets avec un statut ou quelque chose comme ça
Y a-t-il une autre approche? comment te sens-tu à propos de ça?
Réponses:
Si vous entendez représenter des contrôles de règles métier individuels avec des exceptions, je ne pense pas que ce soit une très bonne idée. Plusieurs fois, vous devez signaler plus d'une condition ayant échoué et ne pas vous arrêter sur la première.
D'un autre côté, je crois que la vérification de toutes les règles, puis la levée d'une exception avec le résumé est une bonne pratique.
JamesPoulsonExceptiontant que sous-classe de RuntimeException, puis de fournir l'exception d'origine en tant que cause. Vous pouvez alors simplement dire if (exception instanceof JamesPoulsonException)... de différencier. Utilisez la getCause()méthode pour atteindre l'exception d'origine.
Dans l'exemple que vous nous avez donné, je pense que lever une exception est une mauvaise idée. Si vous savez que l'utilisateur n'est pas autorisé avant de commencer à travailler et que vous lui permettez de faire certaines fonctions, puis de lui donner un message APRÈS avoir terminé la tâche, c'est juste une mauvaise conception.
L'utilisation d'exceptions pour appliquer les règles métier n'est pas une bonne conception.
Je ne vois pas quelle valeur donner une exception à la création d'une bonne logique métier. Il existe des dizaines d'approches de gestion de la logique métier qui n'impliquent pas l'utilisation d'un système destiné à faire face à des conditions inattendues dans le fonctionnement d'un système.
Il est prévu que dans la logique métier, les conditions ne seront pas remplies; c'est la raison de l'avoir en premier lieu, et vous ne voulez pas utiliser le même mécanisme qui gère les échecs d'E / S inattendus, les erreurs de mémoire et les références nulles. Ce sont des défaillances du système, mais la détection de conditions commerciales non satisfaites est le bon fonctionnement du système.
De plus, c'est un système mûr pour des conséquences imprévues. Puisqu'une exception doit être interceptée à un moment donné, vous courez le risque de voir une nouvelle exception de règle métier finie être interceptée quelque part où elle n'est pas prévue ou vous avez la chance d'avoir le code qui recherche des règles métier interceptant des exceptions qui ne sont pas réellement destinées pour ça. Oui, ces conditions peuvent être expliquées par de bonnes pratiques de codage, mais dans tout système non trivial sur lequel plusieurs développeurs travaillent, des erreurs se produiront et il suffit d'espérer qu'elles ne seront pas coûteuses.
exprimer des règles d'affaires est une chose, les mettre en œuvre en est une autre
pensez à l'expérience utilisateur; si l'utilisateur n'est pas un vendeur, pourquoi leur donner un bouton qui dit « créer facture » du tout ?
Cela dépend entièrement de ce qui se fait.
Tout d'abord, quel est le comportement réel que vous souhaitez? Si quelqu'un entre ses propres informations, un rejet et une boîte de dialogue disant, "Vous ne pouvez pas faire cela" sont probablement corrects. S'il s'agit d'une personne chargée de la saisie de données, travaillant à partir d'une pile de formulaires, une boîte de dialogue est probablement également bonne, et la personne chargée de la saisie des données peut placer les formulaires invalides dans une pile spéciale. Si vous effectuez un traitement par lots, vous ne voulez pas interrompre les choses, mais signalez-le et passez au suivant.
Une fois que vous avez le comportement, vous devez décider comment vous allez l'implémenter. Avoir un vérificateur de règles métier qui lève une exception est probablement une bonne idée. Renvoyer un code retour et le faire passer est quelque chose d'autre qui peut mal tourner, et vous ne voulez certainement pas que les entrées erronées continuent.
Ne vous inquiétez pas des dépenses de performance. Dans le cas d'un individu saisissant des données, c'est trivial par rapport aux autres temps impliqués. Typiquement, l'humain prendra le plus de temps dans ce système. Dans le cas d'un travail par lots, si les exceptions sont un problème de performances, vous saisissez beaucoup trop de mauvais enregistrements, et en réalité, la gestion et la nouvelle saisie de tous ces problèmes seront plus problématiques que les exceptions.
Il est très approprié d'avoir une API d'exception robuste et bien conçue qui soit cohérente. L'utiliser pour appliquer les règles métier peut également être approprié. En fait, d'après mon expérience, plus la règle commerciale est compliquée, plus elle est susceptible d'être traitée de cette façon. Il est souvent aussi simple, sinon plus facile, d'écrire un système dans lequel des exceptions sont attendues que d'écrire une logique de branchement faisant autorité.
Cela revient à dire que les règles simples qui peuvent être décrites en une seule phrase doivent généralement être mises en œuvre de manière préventive ou faisant autorité selon le cas. Cependant, si vous avez une règle qui est multidimensionnelle et nécessite plus de trois ou quatre facteurs (en particulier si la sélection de ces facteurs est basée sur un ou plusieurs des autres facteurs), le codage d'exception peut être plus facile à gérer. Souvent, dans ces cas, le chemin logique comporte de nombreuses exceptions de précurseurs qui doivent être levées (vérifie pourquoi l'action ne peut pas être effectuée), puis (ou vice versa), il y a une défaillance de la sécurité (pour vérifier que l'action est autorisée ), il y aura parfois une logique d'accumulation faisant autorité qui doit être vérifiée (disponibilité des descendants / ancêtres, états précurseurs dans lesquels les objets doivent être placés, etc.)
Un avantage qui dérive de ce type de levée d'exceptions est qu'il vous permet de séparer et de réutiliser les exceptions de précurseur dans plusieurs zones de votre projet. (C'est l'essence même de la programmation orientée aspect.) Ce faisant, vous encapsulez un aspect particulier de vos règles commerciales générales dans un composant autonome et maintenable. En général, ces composants correspondront 1-1 aux messages d'erreur lancés. (Bien que parfois vous ayez un composant qui lève plusieurs exceptions différentes, vous ne devriez presque jamais avoir la même exception levée à partir de plusieurs composants.)
À mon avis, il est plus difficile de concevoir des systèmes basés sur des exceptions et le temps de développement initial est plus long, car vous devez créer le processus d'exception à tous les N niveaux. Cependant, ces systèmes finissent généralement par être beaucoup plus stables. Bien qu'il ne soit jamais possible de concevoir un système qui «n'échouera pas», l'avantage de la conception basée sur les exceptions est que vous anticipez toujours une défaillance. Pour la plupart des gens, le processus peut être contre-intuitif. C'est comme demander des directions et demander à quelqu'un de vous dire toutes les rues que vous ne devriez pas activer.