Quand utiliser l'assertion sur les exceptions dans les classes de domaine

Question

Existe-t-il des situations où vous utiliseriez l'assertion au lieu de la gestion des exceptions dans les classes de domaine ...

Answer 1

Utilisez des exceptions pour la validation des paramètres et d'autres contrôles qui vérifient que les utilisateurs de vos classes les utilisent comme prévu.

Utilisez des assertions pour les contrôles de cohérence internes, c'est-à-dire pour indiquer que vous êtes foutu, pas l'utilisateur de votre classe.

Ainsi, si les utilisateurs de votre classe voient un échec d'assertion, ils savent qu'il s'agit (probablement) d'une erreur interne dans votre code, et non dans leur utilisation. D'autre part, si l'exception de validation de paramètre get, ils savent que c'est de leur faute.

Answer 2

Jamais. Les assertions ne constituent pas une forme valide de traitement des erreurs. Utilisez-les pour vous aider à identifier les erreurs de programme lors des tests.

Answer 3

Une assertion reflète un état qui ne devrait jamais se produire et n'était pas attendu, où l'application ne peut pas continuer à s'exécuter pour une raison ou une autre, alors qu'une exception indique un état qui n'est pas considéré comme "normal", mais qui n'était pas inattendu. et à partir duquel il pourrait être possible de récupérer.

Par exemple, si j'alloue de l'espace sur le segment de mémoire et que cette allocation échoue, je ne peux plus continuer à travailler. J'affirme donc que l'adresse renvoyée est valide. si elle est invalide, l'assertion échoue et le programme échoue avec elle.

D’autre part, si j’ouvre un fichier en lecture et que celui-ci n’existe pas, il est alors possible de remédier à cette situation. Dans ce cas, une exception est levée (et interceptée et traitée jusqu’à possible).

En général, les assertions sont les plus utiles pendant la phase de débogage, alors que les exceptions sont considérées comme faisant partie du déroulement normal du programme et du traitement des erreurs. Le consensus général est que les assertions devraient être désactivées dans le code de production (pour protéger les utilisateurs des crashs apparents), alors que j'ai lu une école de pensée qui soutient que cela est contre-productif et que l'utilisateur doit voir l'échec de l'assertion, de sorte qu'il peut correctement signaler le problème.

Personnellement, je combine parfois les deux techniques; généralement, si je détecte une exception qui, à mon avis, ne peut pas être levée. En prenant l'exemple ci-dessus, si je vérifie l'existence du fichier avant d'essayer de l'ouvrir, je ne m'attends pas à une exception, et si c'est le cas, j'ai tendance à le gérer en soulevant une assertion dans le bloc de capture pertinent. Je trouve cette technique particulièrement utile en Java, où de telles exceptions sont entièrement vérifiées.