conditions préalables et exceptions

Question

Supposons que vous ayez une méthode avec certaines conditions préalables et postérieures. Est-il possible de créer une classe d'exception pour chaque condition préalable non réalisée? Par exemple: Ne pas accomplir pre1 signifie lancer une instance notPre1Exception.

Answer 1

Oui et non.

Oui - La violation d'une condition préalable est certainement le moment opportun pour lancer une exception. Lancer une exception plus spécifique simplifiera la capture de cette exception spécifique.

Non - Déclarer une nouvelle classe d'exceptions pour chaque condition préalable de votre programme / API semble excessif. Cela pourrait éventuellement entraîner des centaines ou des milliers d'exceptions. Cela semble être un gaspillage mental et informatique.

Je recommanderais de lancer des exceptions pour les violations de précondition. Je ne recommanderais cependant pas de définir une nouvelle exception pour chaque condition préalable. Au lieu de cela, je recommanderais de créer des classes d'exceptions plus larges couvrant un type de violation précondition, plutôt qu'une violation spécifique. (Je recommanderais également d’utiliser les exceptions existantes où elles s’intègrent bien.)

Answer 2

Pourquoi ne voudriez-vous pas définir PreconditionFailedException (chaîne de précondition)? L'exécution d'un type d'exception différent pour chaque condition préalable ayant échoué est excessive.

Answer 3

Une condition préalable ayant échoué doit déclencher une exception AssertException ou quelque chose de similaire. Avant d'appeler une méthode, sa condition préalable doit être vérifiée. Si l'appelant ne fait pas cette vérification, il s'agit d'un bogue dans le programme ou d'une utilisation incorrecte de la méthode (API).

Answer 4

Si vous ne remplissez pas les conditions préalables, vous ne rencontrerez qu'un événement exceptionnel .

Answer 5

Cela me semble une utilisation utile des exceptions. Cela permet certainement une journalisation et un débogage plus détaillés qu'une simple "condition préalable ayant échoué", bien que vous puissiez également avoir une seule exception "échec des conditions préalables" et indiquer les conditions préalables ayant échoué dans le message d'exception.

Answer 6

Je pense qu'il est correct de créer une exception différente pour toutes vos exceptions tant que vous envisagez de les utiliser et de les gérer.

J'ai constaté que plus la gestion des erreurs et des exceptions est satisfaisante, plus il est facile de déboguer les logiciels au cours des étapes ultérieures.

Par exemple: si vous avez un excypère générique pour gérer toutes les entrées incorrectes, vous devez examiner tout ce qui a été transmis à la méthode en cas d'erreur. Si vous connaissez tous les types de mauvaises conditions, vous saurez exactement où chercher.

Answer 7

Cela me semble possible, mais si vous souhaitez continuer à traiter les conditions préalables, vous obtiendrez N classes d’exception par méthode. Ressemble à une croissance explosive de classes "non fonctionnelles".

J'ai toujours aimé le code où la fonctionnalité "principale" ne traitait pas la violation des conditions préalables (à part de les affirmer - une aide précieuse!). Ce code peut ensuite être encapsulé dans un "vérificateur de précondition" qui fait lancer des exceptions ou notifie la non-satisfaction sinon.

Answer 8

En tant que moyen très général de déterminer si vous devez créer ou non une classe (et une exception est une classe), vous devez déterminer s'il existe un code rendant cette classe unique par rapport à toutes les autres classes (dans ce cas exceptions).

Sinon, je définirais simplement la chaîne dans l'exception et l'appellerais un jour. Si vous exécutez du code dans votre exception (peut-être un mécanisme de récupération générique pouvant gérer plusieurs situations en appelant exception.resolve () ou quelque chose de ce genre), cela pourrait être utile.

Je réalise que les exceptions ne suivent pas toujours cette règle, mais je pense que c'est plus ou moins parce que les exceptions fournies par le langage ne peuvent contenir aucune logique métier (car elles ne connaissent pas l'entreprise - les bibliothèques toujours ont tendance à être pleine d'exceptions aux règles OO)

Answer 9

Je pense que Ben est sur la cible ici. A quoi sert-il de lancer différentes exceptions si vous ne voulez pas les attraper? Si vous voulez vraiment en lancer un autre, j'aurais au moins une commune "PreconditionFailedException". classe de base dont ils sont tous issus et essayez de les organiser en une sorte d’héritage afin que vous puissiez en attraper des groupes. Personnellement, je n’en aurais pas différentes et je n’aurais qu’une exception commune avec les détails de l’échec dans chacune d’elles.

Answer 10

Non, , vous ne devez pas créer d'exception spécifique pour chaque condition préalable, car cela irait à l'encontre des principes de la conception par contrat.

La mise en œuvre des conditions préalables a pour corollaire le fait qu'elles doivent faire partie de la documentation et que vous devez fournir les méthodes nécessaires à l'appelant pour vérifier que toutes les conditions préalables sont valides. (c.-à-d. si l'exécution d'une méthode repose sur le statut d'un objet, la méthode de vérification du statut doit être disponible pour l'appelant).

Ainsi, l'appelant devrait pouvoir vérifier si toutes les conditions préalables sont remplies avant d'appeler votre méthode.

La mise en œuvre d’exceptions spécifiques pour chaque condition préalable violée encouragerait l’appelant à utiliser le schéma try / catch autour de l’appel de méthode, ce qui est en contradiction avec la philosophie de la conception par contrat.

Answer 11

Je dirais que ça va tant que vous créez des exceptions non vérifiées (sous-classe de RuntimeException en Java). Cependant, en Java, il est préférable d’utiliser uniquement des assertions.

Answer 12

Si vous faites cela, assurez-vous qu'ils héritent tous d'une autre exception personnalisée commune.