40 votes

Échecs silencieux en C #, exceptions apparemment non gérées qui ne font pas planter le programme

Dans une application winforms, dans un événement Load du formulaire, ajoutez la ligne suivante:

throw new Exception();

et exécuter l'application. Il a fonctionné sans problème. Cela s'appelle un échec silencieux, vous pouvez essayer d'ajouter messageboxes avant et après, et vous allez bientôt découvrir que, au lieu de planter l'application, l'instruction throw juste sorties de l'événement Load.

Je suis sûr qu'il n'est pas nécessaire d'expliquer comment laide et dangereuse c'est.

Je me demandais néanmoins dans l' (probablement de l'histoire) raisons de cette terrifiante comportement. Je suis sûr que ce n'est pas une décision de conception, probablement pas de choix, ou de la paresse. Quelqu'un sait?

Serait heureux si quelqu'un peut m'indiquer une liste d'événements qui peuvent causer des seilent des échecs aussi.

Voici un extrait de mon code, je n'ai aucune idée de comment il pourrait l'aider, mais, ici, il est:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Windows.Forms;

namespace WindowsFormsApplication1
{
    static class Program
    {
        /// <summary>
        /// The main entry point for the application.
        /// </summary>
        [STAThread]
        static void Main()
        {
            Form f = new Form();
            f.Load += new EventHandler((x, y) => { throw new Exception(); });
            Application.Run(f);
        }

    }
}

MODIFIER Il semble qu'il n'est pas arrivé à tout le monde. J'utilise: fw 3.5, winforms, vs 2008, vista x64, propre projet de winforms, avec le code mentionné ci-dessus.

46voto

Michael Petrotta Points 35647

C'est un problème connu sur les systèmes x64:

C'est un problème connu sur les OS 64 bits la plate-forme. La raison en est que le 64 bits OS de base ne permet pas à l'utilisateur de mode exception à travers kernel mode de piles. L'exception est avalé par OS sliently. Qui se passe dans FormLoad gestionnaire, car elle est appelée dans un OS de rappel. 32bits OS ne fait pas cela, afin de ne pas repro-il.

L'OS de l'équipe étudie liées les questions de. Dans le même temps, vous n'avez pour contourner ce problème. Tournant sur "Arrêt sur l'exception de première chance" sera faire le débogueur de s'arrêter dans ce scénario. Mais il ne l' débogueur s'arrête très souvent, de sorte que vous pouvez le faire seulement quand vous trouver un problème.

Le rapport de bug lié dernière mise à jour de février 2008, et n'indique pas ce qui s'est passé depuis.

Je peux reproduire la plupart des affiches de comportement sur mon système 32 bits ici, et je peux reproduire l'OP comportement sur mon 64 bits (Vista SP2, 3.5SP1 Cadre) de travail PC.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X