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

Il y a une nouvelle fenêtre "Paramètres d'Exception" qui s'affiche dans le volet inférieur droit par défaut lorsque vous commencez le débogage. Il dispose de toutes les options que vous attendez.

Vous pouvez le faire avec CTRL+ALT+E

Cela vous permet de piocher dans les exceptions de provoquer une rupture dans le débogueur.

La clé, cependant, est que vous pouvez également définir si ces exceptions toujours casser, ou break uniquement lorsque c'est une exception non gérée -- mais ce paramètre n'est pas très intuitive.

Vous devez d'abord cocher "Activer uniquement Mon Code" dans Outils > Options > le Débogage.

Ceci vous permet alors de cliquer droit sur l'en-tête de colonne (Pause Quand Jeté) dans les nouvelles Exceptions Paramètres de la fenêtre et ajouter les "Actions Supplémentaires" colonne, qui permet de définir chaque exception, comme "Continuer quand non gérée dans le code de l'utilisateur".

Donc suffit de cliquer-droit sur une exception ou un groupe entier et de désactiver la fonction "Continuer quand non gérée dans le code de l'utilisateur" pavillon. Malheureusement, les "Actions Supplémentaires" colonne apparaîtra vide qui est la même que pour "Casser quand non gérée dans le code de l'utilisateur".

Plus à ce sujet ici:

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

Pour googleurs qui veut casser que lorsque l'exception des préoccupations de leur code, il y a une option dans Visual Studio 2015: Options->Débogage->Général>Juste Mon Code. Une fois la case cochée, elle permet de ne pas casser lorsque l'exception est gérée (jeté et enclenché) à l'extérieur de votre code.

Si je suis correctement lire entre les lignes ici, le problème est que l'exception est effectivement "disparition" même si le débogueur par défaut de comportement devrait briser sur les exceptions non gérées.

Si vous avez des méthodes asynchrones, vous pourriez être en cours d'exécution dans cette question, car des exceptions n'est pas pris sur un thread du pool dans le cadre d'une Tâche de poursuite ne sont pas considérés comme des exceptions non gérées. Plutôt, ils sont absorbés et stockés à la Tâche.

Par exemple, prendre un coup d'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 le débogueur par défaut les paramètres (à l'arrêt sur les exceptions non gérées uniquement), le débogueur s'arrête pas. C'est parce que le thread du pool alloués à la poursuite des hirondelles de l'exception (en passant à l'instance de la Tâche) et libère lui-même de retour à la piscine.

Noter que, dans ce cas, le vrai problème est que les Task retourné par Test() n'est jamais vérifié. Si vous avez le même type de "fire-and-forget" logique dans votre code, alors vous ne verrez pas les exceptions à l'époque, ils sont jetés (même s'ils sont " non gérée à l'intérieur de la méthode), à l'exception ne s'affiche que lorsque vous observez la Tâche par l'attendaient, la vérification de son Résultat ou explicitement, en regardant son Exception.

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

Essayez de suivre les instructions:

1. À l'Exception des Paramètres de fenêtre, ouvrez le menu contextuel par un clic droit dans la fenêtre, puis en sélectionnant Afficher les Colonnes. (Si vous avez désactivé Juste Mon Code, vous ne verrez pas cette commande.)
2. Vous devriez voir une deuxième colonne nommée Actions Supplémentaires. Cette colonne affiche Continuer lorsque non gérée par le code de l'utilisateur sur les exceptions spécifiques, ce qui signifie que le débogueur ne pas se briser si cette exception n'est pas gérée dans le code de l'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 et sélectionnez/désélectionnez l'option Continuer lorsque non Gérée dans le Code de l'Utilisateur) ou pour l'ensemble d'une catégorie d'exceptions (par exemple, tous le Common Language Runtime exceptions).

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

Lorsque j'ai mis à VS2015, j'ai aussi eu des problèmes où des exceptions utilisé pour "casser" de l'application, mais sont maintenant ignorés et passa directement sur. Il ya des moments où nous voulons que notre code de intentionnellement lancer des exceptions dans des endroits où nous voulons que le code pour arrêter, plutôt que de continuer. Nous utilisons toujours la phrase Throw New Exception("Message") pour obtenir notre code intentionnellement pause:

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

Avec VS2015, le classique "du Système.D'Exception" est ce qui est jeté quand nous disons Throw New Exception. Par conséquent, nous avons besoin de vérifier le Système".Exception" à cocher dans le nouveau les Paramètres d'Exception:

Vérifier le Système.Exception Boîte

Une fois la case cochée, le code n'a comme prévu.

Il y a certainement quelques bug dans Visual Studio qui peut l'amener à se coincer nécessitant un redémarrage. Même VS2015.

J'ai eu un seul thread situation où un NullReferenceException était de se faire prendre par un "extérieur" de gestionnaire (toujours dans mon code), même si je l'ai demandé à la pause quand il a été soulevé.

Je réalise que c'est un 'manipulés' exception et vous parlez d'un "non gérée" one - cependant, je suis assez sûr que, parfois, un redémarrage rapide de VS allons résoudre ce problème, si IISRESET ne le fait pas.