N'arrêtez pas le débogueur à CETTE exception quand il est lancé et intercepté

91

Dans les outils / exceptions, j'ai défini l'option selon laquelle le débogueur s'arrête lorsqu'une exception est levée. Qu'il soit attrapé ou non.

Comment exclure une exception à cette règle? Quelque part dans mon code, il y a une exception interceptée qui fait partie de la logique du programme. Donc, je ne veux évidemment pas que cette exception arrête le débogueur chaque fois qu'il est touché.

Exemple: je veux ignorer l'exception de référence nulle (qui est interceptée) à la ligne 344. Je veux m'arrêter à toutes les autres exceptions

c# .net visual-studio-2008 .net-3.5 debugging MichaelD
la source
6
Lorsque cette exception fait partie de votre logique de programmation (pensez-y si vous devez vraiment l'implémenter de cette façon), alors il devrait s'agir au moins d'une exception dérivée créée par vous-même. De cette façon, vous pouvez appliquer la solution de Brian.
tanascius le
Voici le problème: stackoverflow.com/questions/1957907/…
MichaelD
2
@tanascius - +1 Je suis d'accord dans la plupart des cas Les exceptions ne sont pas la meilleure façon de prendre une décision logique; cependant, dans certains cas, comme lorsque la désérialisation de la gestion des exceptions est parfois inévitable, throw> catch> handle est la seule option raisonnable.
jpierson
2
@Et désolé mon mal. La modération de plusieurs onglets à la fois est efficace, mais pas toujours précise.
2
@tanascius: vous devrez peut-être encore intercepter une exception de framework connue avant de pouvoir lancer la vôtre en réponse. Votre suggestion n'est pas toujours possible.
Dan Puzey

Réponses:

40

Si je me souviens bien, vous pouvez utiliser un DebuggerStepThroughattribut sur la méthode qui contient le code que vous ne voulez pas que l'exception se déclenche. Je suppose que vous pouvez isoler le code qui déclenche l'exception ennuyeuse dans une méthode et le décorer avec l'attribut.

Chris Chou
la source
31
D'après la réponse de Malinger et mon expérience, cette réponse semble être incorrecte. L' DebuggerStepThroughattribut n'affecte pas le comportement du débogueur avec les exceptions de première chance.
Michael Petrotta
5
@Tim, j'ai testé et ça ne s'arrête PAS. checkout ma réponse: stackoverflow.com/questions/1420390/3455100#3455100
Shimmy Weitzhandler
1
+1 fonctionne dans VS2010 pour le code .NET 4.0 pur et Silverlight 4 pour les exceptions non gérées.
Mike Post
6
Remarque importante: cela ne fonctionne pas pour les méthodes de type async-await. Plus ici
i3arnon
8
Par MSDN, l' DebuggerStepThroughattribut n'a aucune signification pour le CLR. Il est interprété par les débogueurs. Il semble que cela ne fonctionne pas de manière fiable dans diverses circonstances, et cela DebuggerHiddenfonctionnera de manière fiable stackoverflow.com/a/3455100/141172
Eric J.
64

DebuggerHidden est votre ami!

Le Common Language Runtime n'attache aucune sémantique à cet attribut. Il est fourni pour être utilisé par les débogueurs de code source. Par exemple, le débogueur Visual Studio 2005 ne s'arrête pas dans une méthode marquée avec cet attribut et ne permet pas de définir un point d'arrêt dans la méthode. Les autres attributs du débogueur reconnus par le débogueur de Visual Studio 2005 sont DebuggerNonUserCodeAttribute et DebuggerStepThroughAttribute.

Testé sur VS2010 et fonctionne très bien.

Bien que DebuggerStepThroughsemble également fonctionner pour certaines versions de débogueur spécifiques,DebuggerHidden semble fonctionner pour un plus large éventail de situations en fonction des commentaires des deux réponses.

Notez que les deux options ne fonctionnent actuellement pas avec les méthodes de bloc d'itérateur ou pour les méthodes async / await . Cela pourrait être corrigé dans une mise à jour ultérieure de Visual Studio.

Shimmy Weitzhandler
la source
travaillant sur VS2008. Vous devez l'appliquer à toute la méthode, y compris le bloc catch, ou vous allez simplement casser ailleurs
Mark Heath
1
J'ai ajouté cet attribut à une méthode et le débogueur s'est arrêté à la place sur la méthode d'appel. Est-ce que je manque quelque chose?
Doogal
1
Voilà comment il devrait être. pour éviter cela, vous devrez gérer l'exception ... Ou bien marquer également la méthode de l'appelant DebuggerHidden...
Shimmy Weitzhandler
1
Notez que l'attribut DebuggerStepThrough doit être suffisant pour éviter les ruptures sur les exceptions. DebuggerHidden agit comme une combinaison de DebuggerNonUserCode et de l'attribut DebuggerStepThrough.
jpierson
1
Malheureusement, cela ne fonctionne pas si la méthode en question est une méthode itérative : /
Roman Starkov
14

DebuggerStepThrough est celui à utiliser pour empêcher le débogueur d'interrompre une méthode où il y a un try / catch.

Mais cela ne fonctionne que si vous n'avez pas décoché l'option "Activer juste mon code (géré uniquement)" dans les paramètres généraux des options de débogage de Visual Studio (menu Outils / Options, nœud Débogage / Général) ...

Plus d'informations sur cet attribut sur http://abhijitjana.net/2010/09/22/tips-on-debugging-using-debuggerstepthrough-attribute/

DebuggerHidden empêchera simplement le débogueur d'afficher la méthode où l'exception est levée. Au lieu de cela, il affichera la première méthode de la pile qui n'est pas marquée avec cet attribut ...

Valery Letroye
la source
1
Notez que cela ne fonctionne plus par défaut dans VS 2015, consultez le blog VS pour savoir comment l'activer
bhh
Malheureusement, la solution de contournement VS 2015 ne fonctionne pas pour VS 2019.
Jonathan Allen
13

Les attributs spécifiés dans les autres réponses (et d'autres tels que l' DebuggerNonUserCodeattribut) ne fonctionnent plus de la même manière par défaut dans Visual Studio 2015. Le débogueur se cassera sur les exceptions du marché des méthodes avec ces attributs, contrairement aux anciennes versions de VS. Pour désactiver l'amélioration des performances qui a modifié leur comportement, vous devez modifier un paramètre de registre:

reg add HKCU\Software\Microsoft\VisualStudio\14.0_Config\Debugger\Engine /v AlwaysEnableExceptionCallbacksOutsideMyCode /t REG_DWORD /d 1

Plus d'informations peuvent être trouvées sur le blog de Visual Studio .

(Cela devrait probablement être un commentaire sur la réponse principale mais je n'ai pas assez de représentants)

bhh
la source
3

Vous ne pouvez pas distinguer une exception lancée à un endroit spécifique de votre code. Vous pouvez cependant désactiver les exeptions d'un type spécifique.

Si votre propre code lève l'exception en question, j'en ferais une exception personnalisée, dérivée de ce qui convient, puis désactiverais la rupture de débogage sur ce type dérivé.

La désactivation des exeptions système comme NullReferenceException affectera l'ensemble du système, ce qui n'est bien sûr pas souhaitable pendant le développement.

Notez qu'il existe deux types de comportements de rupture pour les exceptions:

  • Lancé: si cette option est sélectionnée, s'arrête dès qu'une exception de ce type est levée
  • Non gérée par l'utilisateur: si cette option est sélectionnée, s'interrompt uniquement si l'exception, de ce type, n'est pas gérée par un try / catch.

Vous pouvez supprimer l'archivage `` Thrown '' pour NullReferenceException, ce qui vous donnera l'avantage de ne pas casser à chaque fois que votre système passe la ligne en question dans votre code, mais toujours de casser si vous avez une attente de NullReference non gérée dans d'autres parties du système.

Lars Udengaard
la source
3
L'ajout de l'attribut DebuggerStepThrough à une méthode dans Visual Studio 2010 empêchera le débogueur d'arrêter une exception non gérée levée par la méthode.
Tim Murphy
J'ai testé et ça n'empêche pas; ça s'arrête toujours
Shimmy Weitzhandler
1
@Shimmy - Fonctionne pour moi! Assurez-vous que vous appliquez DebuggerStepThrough à chaque méthode à partir du point où il est levé jusqu'au point où vous souhaitez que l'exception devienne visible dans la pile d'appels. Si vous interceptez l'exception et la gérez dans la hiérarchie des appels où toutes les méthodes sont décorées avec DebuggerStepThrough, vous ne devriez jamais voir VS casser sur cette exception.
jpierson