Visual Studio 2015 ne fonctionne pas avec les exceptions non gérées

Visual Studio avait l’habitude d’avoir une case à cocher spécifique pour “Casser une exception non traitée”. En 2015, cela a été supprimé (ou déplacé quelque part, je ne le trouve pas). Alors maintenant, mes projets convertis ne se cassent plus si je ne parviens pas à fournir un gestionnaire d’exceptions de niveau utilisateur. Je ne veux pas casser toutes les “exceptions levées” parce que je gère certaines exceptions. Juste là où je ne parviens pas à fournir un gestionnaire spécifique.

En ce moment, mon code quitte simplement la procédure en cours et continue son exécution à l’emplacement de la stack d’appels suivante, NOT GOOD.

Quelqu’un sait comment le récupérer dans Visual Studio 2015? Je viens de passer à l’édition communautaire hier.

Une nouvelle fenêtre intitulée “Paramètres d’exception” apparaît par défaut dans le volet inférieur droit lorsque vous commencez le débogage. Il a toutes les options que vous attendez.

Vous pouvez l’amener avec CTRL + ALT + E

Cela vous permet de sélectionner les exceptions qui provoquent une rupture dans le débogueur.

La clé, cependant, est que vous pouvez également définir si ces exceptions se brisent toujours ou ne se cassent que lorsqu’il s’agit d’une exception non gérée – mais cela n’est pas très intuitif.

Vous devrez d’abord cocher “Activer mon code” sous Outils> Options> Débogage.

Cela vous permet ensuite de cliquer avec le bouton droit sur l’en-tête de la colonne (Saut lorsque déclenché) dans la nouvelle fenêtre Paramètres des exceptions et d’append la colonne “Actions supplémentaires”, qui vous permet ensuite de définir chaque option comme “Continuer si non gérée dans le code utilisateur”.

Il suffit donc de cliquer avec le bouton droit sur une exception ou sur un groupe entier et de désactiver l’indicateur “Continuer lorsqu’il n’est pas géré dans le code utilisateur”. Malheureusement, la colonne “Actions supplémentaires” apparaîtra vide, ce qui est la même chose que “Casser si non géré dans le code utilisateur”.

entrer la description de l'image ici

Plus sur ceci ici:

http://blogs.msdn.com/b/visualstudioalm/archive/2015/02/23/the-new-exception-settings-window-in-visual-studio-2015.aspx

J’ai eu le même problème et j’ai réussi à le résoudre en procédant ainsi –

  1. Appuyez sur Ctrl + Alt + e pour afficher la fenêtre Paramètres des exceptions .
  2. Cochez Exceptions Common Language Runtime . entrer la description de l'image ici

C’est tout!

J’ai été inspiré par ce post car j’utilise une version x64 de Windows .

Pour googler qui ne veut casser que lorsque l’exception concerne son code, il existe une option dans Visual Studio 2015: Options-> Débogage-> Général-> Juste mon code. Une fois cochée, elle permet de ne pas casser lorsque l’exception est gérée (jetée et interceptée) en dehors de votre code.

Microsoft a subtilement changé la logique dans la nouvelle fenêtre d’exceptions.

Voir http://blogs.msdn.com/b/visualstudioalm/archive/2015/02/23/the-new-exception-settings-window-in-visual-studio-2015.aspx

La partie clé étant:

Notes IMPORTANTES

  • Cette nouvelle fenêtre contient toutes les mêmes fonctionnalités que l’ancienne boîte de dialog modale. Aucune fonctionnalité du débogueur n’a changé uniquement la façon dont vous pouvez y accéder
  • Le débogueur sera toujours interrompu lorsqu’une exception n’est pas gérée
  • Le paramètre à modifier si le débogueur interrompt les exceptions non gérées par l’utilisateur a été déplacé sous un menu contextuel.
  • L’emplacement du menu a été déplacé vers Déboguer -> Windows -> Paramètres d’exception

Cependant , si, comme moi, vous avez un gestionnaire d’exception non géré global dans votre code, le deuxième élément de cette liste est la clé: aucune exception ne sera véritablement non gérée, ce qui semble être différent de VS2013.

Pour récupérer le comportement où VS brise les exceptions non gérées, j’ai dû cocher tous les types d’exception que je voulais casser et ensuite vérifier que les “Options supplémentaires” (vous devrez peut-être rendre cette colonne visible *) pour “Continue lorsqu’il n’est pas géré dans le code utilisateur “n’a PAS été défini. La logique VS2015 ne semble pas considérer que mon gestionnaire d’exceptions global non géré est “géré dans le code utilisateur”, de sorte qu’il ne fonctionne pas correctement . cependant, il ne brise pas les exceptions sockets. Cela rend le travail comme VS2013 l’a fait.

* Comment activer la colonne “Actions supplémentaires” * Comment activer la colonne

Si je lis correctement entre les lignes ici, le problème est que votre exception est en train de «disparaître» même si le comportement du débogueur par défaut doit casser les exceptions non gérées.

Si vous avez des méthodes asynchrones, vous pouvez rencontrer ce problème car les exceptions qui ne sont pas interceptées sur un thread de pool de threads dans le cadre d’une continuation de tâche ne sont pas considérées comme des exceptions non gérées. Au contraire, ils sont avalés et stockés avec la tâche.

Par exemple, regardez ce code:

 class Program { static void Main(ssortingng[] args) { Test(); Console.ReadLine(); } private async static Task Test() { await Task.Delay(100); throw new Exception("Exception!"); } } 

Si vous exécutez ce programme avec les parameters du débogueur par défaut (arrêtez uniquement les exceptions non gérées), le débogueur ne sera pas interrompu. Cela est dû au fait que le thread du pool de threads alloué à la suite avale l’exception (en la transmettant à l’instance Task) et se libère dans le pool.

Notez que dans ce cas, le vrai problème est que la Task renvoyée par Test() n’est jamais cochée. Si vous avez des types similaires de logique “fire-and-forget” dans votre code, vous ne verrez pas les exceptions au moment où elles sont lancées (même si elles sont “non gérées” dans la méthode); l’exception ne s’affiche que lorsque vous observez la tâche en l’attendant, en vérifiant son résultat ou en examinant explicitement son exception.

C’est juste une supposition, mais je pense qu’il est probable que vous observiez quelque chose comme ça.

D’après mon expérience, les parameters d’exception en 2015 sont complètement déformés si vous changez quelque chose.

On s’attend à ce que, jusqu’au groupe parent «CLR», vous ne deviez pas vous retrouver à court d’exécution. Vous allez toujours casser si une exception n’est pas gérée. Mais si le groupe CLR est décoché, le code dans un try … catch ne devrait tout simplement pas provoquer de rupture. Ce n’est pas le cas.

Solution: Dans la nouvelle boîte à outils des parameters d’exception, cliquez avec le bouton droit de la souris et choisissez “restaurer les parameters par défaut”. Taadaaaa … Il se comporte normalement à nouveau. Maintenant, ne le vis pas.

Essayez de suivre les instructions:

  1. Dans la fenêtre Paramètres des exceptions, ouvrez le menu contextuel en cliquant avec le bouton droit de la souris sur la fenêtre, puis en sélectionnant Afficher les colonnes. (Si vous avez désactivé Just My Code, vous ne verrez pas cette commande.)
  2. Vous devriez voir une deuxième colonne nommée Actions supplémentaires. Cette colonne affiche Continuer si elle n’est pas gérée par le code utilisateur sur des exceptions spécifiques, ce qui signifie que le débogueur ne se casse pas si cette exception n’est pas gérée dans le code utilisateur mais est gérée dans le code externe.
  3. Vous pouvez modifier ce paramètre pour une exception particulière (sélectionnez l’exception, cliquez avec le bouton droit de la souris et sélectionnez / désélectionnez Continuer lorsqu’il est non géré dans le code utilisateur) ou pour une catégorie entière d’exceptions (par exemple, toutes les exceptions Common Language Runtime).

https://msdn.microsoft.com/en-us/library/x85tt0dd.aspx

C’est un peu déroutant, et à mon avis pas aussi bon que l’ancien dialog sur les exceptions, mais de toute façon.

Si une exception est dans la liste et cochée, le débogueur se brisera chaque fois que l’exception sera levée.

Si une exception est décochée ou non dans la liste, le débogueur ne sera interrompu que si ce type d’exception n’est pas géré par l’utilisateur.

Par exemple, dans la capture d’écran ci-dessous, le débogueur se brisera chaque fois qu’une System.AccessViolationException sera levée, mais pour toutes les autres exceptions, il ne sera rompu que si l’exception n’a pas été gérée par l’utilisateur.

Fenêtre d'outils d'exceptions Visual Studio 2015

Lorsque j’ai effectué la mise à niveau vers VS2015, j’avais également des problèmes où les exceptions étaient utilisées pour “casser” l’application, mais qui sont maintenant ignorées et transmises immédiatement. Il y a des moments où nous voulons que notre code lance intentionnellement des exceptions là où nous voulons que le code s’arrête, plutôt que de continuer. Nous utilisons toujours l’expression Throw New Exception("Message") pour que notre code soit intentionnellement rompu:

  If SomethingReallyBad = True Then Throw New Exception("Something Really Bad happened and we cannot continue.") End If 

Avec VS2015, le classique “System.Exception” est ce qui est lancé quand on dit Throw New Exception . Par conséquent, nous devions cocher la case “System.Exception” dans les nouveaux parameters d’exception:

Vérifiez la boîte System.Exception

Une fois vérifié, notre code a fait comme prévu.

La solution à cela est sémantiquement le contraire de ce que vous pensez que vous définissez. Vous devez vous assurer que l’ option Continuer lorsqu’elle n’est pas gérée dans le code utilisateur n’est pas activée, c’est- à- dire qu’elle n’est pas cochée dans la colonne Actions supplémentaires de l’onglet Paramètres d’exception – voir ci-dessous:

vous dites effectivement ne pas continuer (c.-à-d. pause) lorsqu’il n’est pas géré dans le code

Fenêtre Paramètres d'exception (Contrôle + Alt + E)

Pour faire ça:

  1. Cliquez avec le bouton droit de la souris sur l’exception ou le jeu d’exceptions dont vous vous souciez (c’est-à-dire généralement la ligne supérieure «Exceptions Common Language Runtime» dans l’arborescence).
  2. Sélectionnez l’option Continuer si non géré dans le code utilisateur (voir ci-dessous)
  3. Assurez-vous que les exceptions ne sont pas cochées (voir ci-dessous)
  4. continuer le débogage

entrer la description de l'image ici

Cela l’a fait pour moi – encore heureux.

C’était dans VS 2015

Il y a certainement un bogue dans Visual Studio qui peut entraîner un blocage nécessitant un redémarrage. Même VS2015.

J’ai eu une situation unique où une NullReferenceException était interceptée par un gestionnaire «externe» (toujours dans mon code), même si je lui avais demandé de rompre quand il a été déclenché.

Je me rends compte que c’est une exception «manipulée» et que vous parlez d’une exception «non gérée» – mais je suis presque certain que parfois un redémarrage rapide de VS résoudra ce problème si IISRESET ne le fait pas.