Selon le .NET Framework Référence générale: Erreur Les directives de levage et de manutention exceptions ne doivent pas être levées pendant les opérations «normales». L'entrée utilisateur invalide est-elle sur un formulaire Web, disons que l'utilisateur entre un nom en double, considéré comme normal? EDIT:
Un peu plus d'arrière-plan: je m'interroge sur l'approche à la validation du modèle préconisée par un livre que je lis. Le livre suggère de lancer une exception personnalisée à partir d'un référentiel lorsqu'il est fourni avec des données non valides à enregistrer. Maintenant, cela me semble enfreindre les directives de la SP, car vous utilisez des exceptions comme contrôle de flux ... à moins que la réception de données non valides ne se considère en dehors de l'opération «normale». Je veux juste voir s'il y a de nouvelles directives d'une source fiable pour résoudre ce problème.
Une autre modification:
OK SO
9 Réponses :
Entrée d'une manière générale, invalide ou mal formée ne considère pas "exceptionnelle" et devrait être traitée à l'aide d'une autre exception. Mais notez qu'il s'agit d'une ligne directrice - il se peut que l'utilisation des exceptions pour gérer le problème entraînerait un meilleur code.
Code complet par Steve McConnell fournit une liste de chèques pour la programmation défensive qui est vraiment bonne. Sous le sujet des exceptions, il comprend:
Mon sentiment est que la programmation défensive doit toujours être gérée par la méthode prise dans les données. Donc, jeter une exception ne serait pas approprié.
Il y a toujours des circonstances atténuantes, bien sûr.
Une exception est quelque chose qui est exceptionnel - c'est pourquoi ils sont appelés exceptions. La mauvaise entrée de l'utilisateur n'est pas une exception, en règle générale, et doit être traitée gracieusement avec un type de notification audit utilisateur. En outre, n'oublions pas que les exceptions tuent vraiment la performance de votre code.
http://blogs.msdn.com/kcwalina /Rarchive/2005/03/16/396787.aspx http://msdn.microsoft.com/en-us/magazine/dd419661. ASPX
À quel point votre code devrait-il être performant dans les événements axés sur l'interface utilisateur? S'inquiéter de la performance des exceptions est une perte de temps, sauf si vous l'avez identifié comme une cause de code mal performant.
Pas complètement juste. Les exceptions sont appelées exceptions parce que quelqu'un, probablement leur inventeur, les a appelés comme ça. Votre argument me rappelle "un chat a une queue plus encore alors pas de chat. Aucun chat n'a deux queues, d'où un chat doit avoir trois" . Cela dit, vous avez probablement toujours raison de ne pas utiliser la manipulation des exceptions ici.
Une entrée d'utilisateur non valide est une situation attendue. Vous vous attendez à ce que cela se produise souvent comme une entrée valide. Quand alors, jeter des exceptions pourraient être trop.
D'autre part, vous pouvez lancer des exceptions personnalisées et les attraper en interne si vous préférez ce style de code pour certaines raisons. Mais une entrée d'utilisateur non valide ne doit pas lancer ce type d'exception qui empêcherait votre application complètement.
En supposant que la première vérification des données est dans l'interface utilisateur, que se passe-t-elle lorsque la validation de l'interface utilisateur ne se produit pas ou ne devient pas obsolète et est en désaccord avec une implémentation plus profonde (c'est-à-dire des contraintes de base de données, une logique de domaine, etc.)? Un conflit en mérite logique étant-il exceptionnel?
L'interface utilisateur ne passerait pas l'exécution sur BL jusqu'à ce que l'entrée soit correcte, BL vérifierait à nouveau et renvoie le résumé de la validation sans soulever une exception, l'intégrité de la base de données est la dernière ligne de défense et il devrait déjà soulever une exception parce que le fait qu'une erreur soit une erreur. Vous avez eu si la base de données indique que quelque chose est profondément faux.
Si vous validez explicitement la contribution de l'utilisateur contre certains critères et prévoyez de prendre des mesures en fonction du résultat de cette validation, vous le trouverez beaucoup plus facile si vous ne lancez pas d'exceptions.
Voici comment vous le faites:
du côté de la base de données, vous lancez si vous essayez de créer un nouvel enregistrement d'utilisateur avec un nom duplicate. C'est une situation exceptionnelle et vous ne pouvez rien faire de la base de données. Vous fournissez également des méthodes pour vérifier la disponibilité des noms d'utilisateur.
sur le côté UI, vous permettez à l'utilisateur de sélectionner un nom, puis vérifiez sa disponibilité. C'est la responsabilité du côté de l'UI d'interagir avec l'utilisateur et de leur dire de choisir un autre nom. Avec la possibilité de vérifier la validité du nom, l'interface utilisateur ne doit jamais passer à un nom en double ... Je suis d'accord avec le livre dans ce cas. Votre base de données est le niveau le plus bas de votre application et ne devrait pas avoir trop de logique commerciale codée (si cela se produit, alors faire B, sauf si c, puis d). Cela ne signifie pas que vous ne pouvez pas fournir de méthodes utiles dans votre couche de données que vous pouvez utiliser pour éviter les exceptions.
C'est très la raison de la façon dont nous avons mis en œuvre. La "règle générale" est que le plus proche de l'interface utilisateur que la validation se produise, le plus léger est. Nous avons la validation à plusieurs niveaux, avec l'objectif ultime de prévenir une découverte plus chère de données mauvaises (c'est-à-dire une sqlexception). Dans notre approche DDD, nous appliquons strictement la validité de l'objet, avec le "quelque chose d'exceptionnel" étant que les données n'étaient pas validées ni les règles de validation sont en contradiction avec la mise en œuvre.
généralement non, mais je peux penser à une exception à la règle que j'ai personnellement rencontrée.
Nous exigeons que nos objets de domaine soient valides à tout moment. Si une tentative est faite pour créer ou transmettre des données mauvaises, nous avons lancé une exception à partir de l'objet de domaine. Dans ce cas, cependant, c'est une "circonstance exceptionnelle". Pourquoi? La logique est que les mauvaises données ne doivent jamais entrer dans le domaine. Quelque part le long de cette pile d'appel est un endroit où des données non valides ont pu être entrées dans le système - qu'il s'agisse d'une erreur de calcul, de mauvaises données de la source de données sous-jacente ou de l'entrée de l'utilisateur.
Une autre raison accessoire Nous faisons cela, c'est que les objets de domaine et leurs règles sont encapsulés dans un ensemble physiquement séparé. En faisant cela, nous nous assurons que nous fournissons autant d'informations à l'appelant, le plus possible. En raison des conséquences de ce qui se passe, l'hypothèse est faite que l'appelant se logera de sorte qu'il existe une visibilité sur ce qui est vraiment un problème - celui de ne pas valider les données.
Donc, dans le cas où vous cherchez à voir si les données n'ont pas été validées ou que les règles de validation sont en contradiction avec vos méthodes / fonctionnalités de persistance de données, je pense qu'il est parfaitement valide à lancer. Dans tous les autres cas, j'ai tendance à éviter de lancer une entrée non valide.
Je suis d'accord avec d'autres réponses que la mauvaise entrée est attendue et ne doit pas être traitée avec une exception. Cependant, si vous découvrez une entrée malveillante (tentative d'injection SQL ou quelque chose comme ça), une exception peut être appropriée.
J'ai entendu et j'ai lu que les bonnes pratiques OO ne feraient pas une exception pour la saisie de l'utilisateur. Cependant, cette logique me fait gratter ma tête un peu aussi. Pensez à l'histoire ici. Retour en programmation C, je pourrais écrire une fonction telle que: L'appelant ferait quelque chose comme: aussi loin que moi Peut se souvenir, la manutention des exceptions a été écrite pour s'éloigner des conditions d'erreur de retour en tant que valeur de retour pour des méthodes telles que indiquées ci-dessus. Pourtant, si je n'utilise pas de manutention d'exception pour la validation des informations utilisateur, je ne suis pas revenu à retourner une condition sur les mauvaises données qui me font que je dispose d'une instruction IF pour vérifier les données non valides pour modifier mon flux d'exécution "réussi"? Maintenant, il semble que je dois vérifier les valeurs de retour et envelopper en essayez / attraper. La méthode validateuserInfo dans une classe C ++ / C # / Java pourrait organiser une exception pour une "erreur exceptionnelle" et renvoyer les erreurs de validation "de mauvaises données" comme une valeur de retour ou un autre mécanisme. N'est-ce pas qui rend le code plus complexe pour une "règle oo"? Bien sûr, un puriste OO reviendra avec une alternative de telle sorte que je n'ai pas obligé de renvoyer l'erreur de validation "de mauvaises données" Dans une tentative d'annulation de ce scénario, mais le fait est que quelque part, quelqu'un écrira du code pour vérifier l'erreur de validation et écrire un bloc d'essai / attraper pour des exceptions. Si la manipulation des exceptions est lente, les développeurs de compilateur doivent le réparer pour le rendre plus rapide. Cela ne devrait pas être une raison pour éviter les exceptions.
Un nom dupliqué serait probablement une exception. Un numéro de téléphone invalide serait un meilleur exemple d'une erreur non critique.
Basé sur votre édition, je suis d'accord avec le livre que vous lisez. Quel livre parlez-vous? La couche contenant mes entités, à mon avis, devrait être garantie pour être valide - de transmettre des données non valides pour eux signifie que quelque chose est incorrect supérieur à la pile - s'il manque une validation manquante / invalide, la modification des exigences non imprégnées via la pile, etc.
Il est important de noter que, dans de nombreux cas, la validité des données d'entrée à un moment donné peut suggérer, mais ne pas prouver que l'entrée sera valide à tout moment futur. Il faut être préparé pour les cas où les données qui ont été jugées valides deviennent invalides entre le moment où elle est vérifiée et l'heure utilisée. La validité de la vérification préalable peut être utile pour améliorer l'expérience utilisateur et fournir des méthodes "Essayez" pour éviter que des exceptions lancées peuvent être utiles dans les cas, le code d'appel serait prêt à gérer . Quel problème avez-vous eu avec des exceptions?
Le service doit désormais spécifier des contradictoires défectueuses pour l'exception et jeter les exceptions comme défaillante s. De plus, tout le code client doit être modifié pour attraper la défaillance à la place. Si j'ai spécifié dans l'interface une méthode de retour de données non valides que j'aurais pu continuer à utiliser les interfaces existantes sans modification supplémentaire.
@Paul: Si les interfaces avaient promis de renvoyer des données valides, changez la spécification en faveur de la promesse, ce serait un changement de rupture encore pire que de jeter des exceptions, n'est-ce pas?
Tout d'abord, interface! = Contrat de données. Relad the Op, ceci est pour la validation du modèle lors de la validation des données. Le client doit savoir quelle est la raison pour laquelle une validation est rejetée afin d'informer l'utilisateur. Aucun client ne doit être mis en œuvre qui rejette simplement la contribution sans explication, ces exceptions d'intrants non valides ne sont donc pas vraiment des «exceptions» du point de vue du programme, mais une partie normale de la logique commerciale et aurait dû être mise en œuvre à tel.