Pouvez-vous définir VS2008 pour casser une erreur dans une instruction try-catch

Question

Une des choses que j'ai aimé à propos de VB6 est que vous aviez la possibilité de dire à l'environnement de développement de casser toutes les erreurs indépendamment de la gestion des erreurs en haut Est-il possible de faire la même chose dans VS2008 afin que le débogueur s'arrête sur n'importe quelle erreur même si cela se passe dans une instruction try-catch? Le problème est particulièrement difficile lorsque vous traitez un fichier avec dis 500 enregistrements et qu'il échoue sur l'un d'entre eux - qui sait lequel - Vous ne voulez pas modifier le code pour que votre compteur soit initialisé à l'extérieur que pour la boucle - c'est bâclé à long terme. Vous voulez juste que le débogueur sache s'arrêter à cause d'un réglage que vous avez mis quelque part.

Answer 1

Oui, allez dans le menu "Mise au point", sélectionnez "Exceptions ...", cochez la case "Jeté" pour "Common Language Runtime Exceptions"

Answer 2

Bien sûr, appuyez sur Ctrl-Alt-E pour afficher la fenêtre des exceptions et cochez la jeté case Common Language Runtime Exceptions

qui arrêtera l'exécution, ouvrez le code source où l'exception a été lancée, et vous dire avec une fenêtre de message quelle erreur il est, en montrant la ligne était jeté.

Answer 3

Dans Visual Studio, vous pouvez accéder à Déboguer -> Exceptions ... et cocher la case à cocher à une exception particulière ou à une classe d'exceptions que vous voulez que VS casse lorsqu'il est généré.

Il existe cinq catégories d'exceptions: C++, Common Language Runtime, Assistants de mise au point gérée, Vérifications d'exécution natives et Win32. Pour la plupart, vous êtes intéressé par les CLR, mais si vous faites de l'interopérabilité COM, vous pourriez aussi en vouloir d'autres.

Answer 4

J'ai découvert cette case à cocher dont tout le monde parle pendant le débogage d'un projet au travail une fois. Je l'ai allumé et tout d'un coup je reçois toutes ces exceptions jetées partout! Il s'est avéré que les développeurs d'une autre équipe utilisaient Try-Catch comme masque pour des conditions facilement évitables (mais étaient trop paresseux pour se piéger). MAL!