La pause de Visual Studio 2015 sur les exceptions non gérées ne fonctionne pas
Auparavant, Visual Studio avait une case à cocher spécifique pour "Interrompre une exception non gérée". En 2015, cela a été supprimé (ou déplacé quelque part, je ne le trouve pas). Alors maintenant, mes projets convertis ne s'arrêtent plus si j'échoue à fournir un gestionnaire d'exceptions au niveau utilisateur. Je ne veux pas interrompre toutes les "exceptions levées" car je gère des exceptions spécifiques. Juste où je ne parviens pas à fournir un gestionnaire spécifique.
À l'heure actuelle, mon code quitte simplement la procédure en cours et continue l'exécution au prochain emplacement de la pile d'appels, PAS BON.
Quelqu'un sait comment récupérer cela dans Visual Studio 2015? Je viens de passer à l'édition communautaire hier.
Une nouvelle fenêtre appelé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 en parler avec CTRL+ALT+E
Cela vous permet de choisir quelles exceptions entraînent une rupture du débogueur.
La clé, cependant, est que vous pouvez également définir si ces exceptions doivent toujours être interrompues, ou uniquement si elles sont non traitées, mais le réglage n'est pas très intuitif.
Vous devrez d'abord cocher "Activer uniquement mon code" sous Outils> Options> Débogage.
Cela vous permet ensuite de cliquer avec le bouton droit de la souris sur l'en-tête de la colonne (Couper lorsque levé) dans la nouvelle fenêtre Paramètres d'exception et d'ajouter la colonne "Actions supplémentaires", ce qui vous permet ensuite de définir chaque exception comme "Continuer sans traitement dans le code utilisateur".
Il suffit donc de cliquer avec le bouton droit de la souris sur une exception ou sur un groupe entier et de désactiver le drapeau "Continuer sans code dans le code utilisateur". Malheureusement, la colonne "Actions additionnelles" sera vide, ce qui est identique à "Interrompre si non géré dans le code utilisateur".
Plus sur ceci ici:
J'ai eu le même problème et j'ai réussi à le résoudre en faisant ceci -
- Presse Ctrl + Alt + e pour faire apparaître la fenêtre Paramètres d'exception.
- Cochez les exceptions du Common Language Runtime .
![enter image description here]()
C'est tout!
J'ai été inspiré par ce post puisque j'utilise une version x64 de Windows.
Pour googler qui veut interrompre uniquement lorsque l'exception concerne son code, il existe une option dans Visual Studio 2015: Options-> Débogage-> Général-> Seulement mon code. Une fois coché, cela permet de ne pas casser quand l’exception est gérée (levée et attrapée) en dehors de votre code.
Microsoft a subtilement modifié la logique dans la nouvelle fenêtre des exceptions.
La partie clé étant:
Notes IMPORTANTES
- Cette nouvelle fenêtre contient les mêmes fonctionnalités que l’ancien dialogue modal. Aucune des fonctionnalités du débogueur n'a changé que 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 tombe en panne avec des exceptions non gérées par l'utilisateur a été déplacé dans un menu contextuel.
- L'emplacement du menu a été déplacé vers Debug -> Windows -> Exception Settings
Cependant, si comme moi vous avez un Global Unhandled Exception Handler dans votre code, le deuxième élément de cette liste est essentiel: pour moi, aucune exception ne sera donc vraiment non gérée, ce qui semble être le cas. différent de VS2013.
Pour retrouver le comportement où VS interrompt les exceptions non gérées, je devais cocher tous les types d'exceptions que je voulais interrompre, puis m'assurer que les "Options supplémentaires" (vous devrez peut-être rendre cette colonne visible *) pour "Continuer". Lorsque le code utilisateur ne le gère pas "était PAS défini. La logique de VS2015 ne semble pas considérer que mon gestionnaire d'exception globale non gérée} est "traité en code utilisateur", il est donc cassé; il ne se casse pas sur les exceptions capturées cependant. Cela le fait fonctionner comme VS2013 l'a fait.
* Comment activer la colonne "Actions additionnelles" 
Si je lis correctement entre les lignes ici, le problème est que votre exception est effectivement "en train de" disparaître, même si le comportement du débogueur par défaut devrait se rompre avec les exceptions non gérées.
Si vous avez des méthodes asynchrones, vous risquez de rencontrer ce problème car les exceptions non 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, jetez un oeil à ce code:
class Program
{
static void Main(string[] 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 paramètres de débogueur par défaut (arrêter uniquement les exceptions non gérées), le débogueur ne sera pas interrompu. En effet, le thread de pool de threads alloué à la continuation avalise l'exception (en la transmettant à l'instance de tâche) et se libère à nouveau dans le pool.
Notez que, dans ce cas, le vrai problème est que la Task renvoyée par Test() n'est jamais vérifiée. Si votre code contient des types de logique 'fire-and-oublier' similaires, 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 regardant 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 paramètres d'exception de 2015 sont complètement déréglés si vous changez quelque chose.
Si vous attendez jusqu'à ce que le groupe parent "CLR" apparaisse, vous ne devriez recevoir aucune exception de rupture sans traitement. Vous ferez toujours une pause si une exception n'est pas gérée. Mais, si vous avez décoché le groupe CLR, le code dans une tentative ... catch ne devrait tout simplement pas causer de rupture. Ce n'est pas le cas.
Solution: Dans la nouvelle boîte à outils des paramètres d'exception, cliquez avec le bouton droit de la souris et choisissez "restaurer les paramètres par défaut". Taadaaaa ... Il se comporte normalement à nouveau. Maintenant, ne vis pas avec ça.
Essayez de suivre les instructions:
- Dans la fenêtre Paramètres d'exception, ouvrez le menu contextuel en cliquant avec le bouton droit de la souris dans la fenêtre, puis en sélectionnant Afficher les colonnes. (Si vous avez désactivé Just My Code, vous ne verrez pas cette commande.)
- Vous devriez voir une deuxième colonne nommée Actions supplémentaires. Cette colonne affiche Continuer lorsqu'elle n'est pas gérée par le code utilisateur sur des exceptions spécifiques, ce qui signifie que le débogueur ne rompt pas si cette exception n'est pas gérée dans le code utilisateur mais dans le code externe.
- 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 si non géré dans le code utilisateur) ou pour toute une catégorie d'exceptions (par exemple, toutes les exceptions Common Language Runtime).
C'est un peu déroutant, et à mon avis pas aussi bon que l'ancien dialogue des exceptions, mais quand même.
Si une exception est dans la liste et cochée, le débogueur sera interrompu chaque fois que l'exception sera levée.
Si une exception n'est pas cochée ou ne figure pas dans la liste, le débogueur s'interrompt uniquement lorsque ce type d'exception est non géré par l'utilisateur.
Par exemple, dans la capture d'écran ci-dessous, le débogueur se rompt chaque fois qu'un System.AccessViolationException est lancé, mais pour toutes les autres exceptions, il ne le sera que si l'exception n'a pas été gérée par l'utilisateur.
Lorsque j'ai effectué la mise à niveau vers VS2015, des problèmes se produisaient également lorsque des exceptions "cassaient" l'application, mais étaient maintenant ignorées et transmises immédiatement. Il y a des moments où nous voulons que notre code intentionnellement jette des exceptions dans des endroits 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 rompt intentionnellement:
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é lorsque nous disons Throw New Exception. Par conséquent, nous devions cocher la case "System.Exception" dans les nouveaux paramètres d'exception:
Cochez la case System.Exception
Une fois vérifié, notre code a fonctionné comme prévu.
La solution est que c’est sémantiquement le contraire de ce que vous pensez être en train de définir. Vous devez vous assurer que Continue lorsqu'il n'est pas géré dans le code utilisateur est non activé c'est-à-dire n'est pas coché comme indiqué dans la colonne Actions supplémentaires dans le Exception paramètres onglet - voir ci-dessous:
vous dites effectivement (ne continuez pas (c.-à-d. une pause) lorsque le code n'est pas géré}
Pour faire ça:
- Cliquez avec le bouton droit de la souris sur l'exception ou l'ensemble des exceptions qui vous intéressent (c'est-à-dire généralement la ligne supérieure "Exceptions du langage commun" dans l'arborescence).
- Sélectionnez l'option Continuer sans traitement dans le code utilisateur (voir ci-dessous).
- Assurez-vous que les exceptions sont non vérifiées (voir ci-dessous)
- continuer le débogage
C'est ce qui a été fait pour moi - heureux à nouveau.
C'était au VS 2015
Il y a certainement un bogue dans Visual Studio qui peut le bloquer et nécessiter un redémarrage. Même VS2015.
J'avais un seul cas de thread où une NullReferenceException était interceptée par un gestionnaire 'externe' (toujours dans mon code), même si je l'avais demandé à la casse quand elle était levée.
Je sais que c'est une exception "traitée" et que vous parlez d'une "non gérée" - cependant, je suis à peu près sûr que parfois, un redémarrage rapide de VS résoudra ce problème, si IISRESET ne le fait pas.
Visual Studio 2017 fonctionne parfaitement avec la gestion des erreurs. Visual Studio 2015, quant à lui, craint la gestion des erreurs avec les tâches car, en mode débogage, toutes les exceptions qui se produisent dans une tâche asynchrone sont interceptées, mais si j'interviens, elle se bloque indéfiniment. S'il est exécuté sans débogage, il se bloque indéfiniment sans exception capturée !!! J'adore Visual Studio et je l'utilise depuis 1995 et 2015 est de loin la pire version, bien que j'aie sauté directement de 2010 à 2015. J'ai passé 8 heures à essayer de faire en sorte que cette exception fonctionne sans succès. J'ai copié le code exact jusqu'en 2017 sur mon ordinateur personnel et cela a parfaitement fonctionné. Je suis très irrité par le fait que Microsoft ait poussé les tâches dans un cadre que le compilateur 2015 ne peut pas gérer correctement.