J'ai lu de nombreux articles (et quelques autres questions similaires qui ont été publiées sur StackOverflow) sur la manière et le moment d'utiliser les assertions, et je les ai bien comprises. Mais encore, je ne comprends pas quel genre de motivation devrait me pousser à utiliser Debug.Assert
au lieu de lancer une simple exception. Ce que je veux dire, c'est que dans .NET, la réponse par défaut à une assertion échouée est «d'arrêter le monde» et d'afficher une boîte de message à l'utilisateur. Bien que ce type de comportement puisse être modifié, je trouve cela très ennuyeux et redondant de le faire, alors que je pourrais plutôt lancer une exception appropriée. De cette façon, je pourrais facilement écrire l'erreur dans le journal de l'application juste avant de lancer l'exception, et de plus, mon application ne se fige pas nécessairement.
Alors, pourquoi devrais-je, le cas échéant, utiliser Debug.Assert
au lieu d'une simple exception? Placer une assertion là où elle ne devrait pas être pourrait simplement provoquer toutes sortes de "comportements indésirables", donc à mon avis, je ne gagne vraiment rien en utilisant une assertion au lieu de lancer une exception. Êtes-vous d'accord avec moi ou est-ce que je manque quelque chose ici?
Remarque: Je comprends parfaitement quelle est la différence "en théorie" (Debug vs Release, modèles d'utilisation, etc.), mais comme je le vois, je ferais mieux de lancer une exception au lieu d'effectuer une assertion. Puisque si un bogue est découvert sur une version de production, je voudrais toujours que "l'assertion" échoue (après tout, le "surcoût" est ridiculement petit), donc je ferai mieux de lancer une exception à la place.
Edit: La façon dont je le vois, si une assertion échoue, cela signifie que l'application est entrée dans une sorte d'état corrompu et inattendu. Alors pourquoi voudrais-je continuer l'exécution? Peu importe si l'application s'exécute sur une version de débogage ou de publication. La même chose vaut pour les deux