Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Le Common Language Runtime permet à la plupart des exceptions non gérées dans les threads de continuer naturellement. Dans la plupart des cas, cela signifie que l’exception non gérée entraîne l’arrêt de l’application. Toutefois, le Common Language Runtime fournit un backstop pour certaines exceptions non gérées utilisées pour contrôler le flux du programme :
Une ThreadAbortException est levée dans un thread, car Abort a été appelé. Cela s’applique uniquement aux applications .NET Framework.
Une AppDomainUnloadedException est levée dans un thread, car le domaine d’application dans lequel le thread s’exécute est en cours de déchargement.
Le Common Language Runtime ou un processus hôte met fin au thread en lève une exception interne.
Si l’une de ces exceptions n’est pas prise en charge dans les threads créés par le Common Language Runtime, l’exception met fin au thread, mais le Common Language Runtime n’autorise pas l’exception à poursuivre.
Si ces exceptions ne sont pas gérées dans le thread principal ou dans les threads qui ont entré le runtime à partir du code non managé, elles se poursuivent normalement, ce qui entraîne l’arrêt de l’application.
Remarque
Il est possible que le runtime lève une exception non gérée avant qu’un code managé n’ait eu la possibilité d’installer un gestionnaire d’exceptions. Même si le code managé n’a pas eu la possibilité de gérer une telle exception, l’exception est autorisée à se poursuivre naturellement.
Mettre en lumière des problèmes de threads au cours du développement
Lorsque les threads sont autorisés à échouer en mode silencieux, sans mettre fin à l’application, de graves problèmes de programmation peuvent ne pas être détectés. Il s’agit d’un problème particulier pour les services et d’autres applications qui s’exécutent pendant des périodes prolongées. À mesure que les threads échouent, l’état du programme devient progressivement endommagé. Les performances de l’application peuvent se dégrader, ou l’application peut ne pas répondre.
Autoriser les exceptions non gérées dans les threads à continuer naturellement, jusqu’à ce que le système d’exploitation termine le programme, expose ces problèmes pendant le développement et le test. Les rapports d’erreurs sur les arrêts du programme prennent en charge le débogage.
Remplacement d’hôte
Un hôte non managé peut utiliser l’interface ICLRPolicyManager dans l’API d’hébergement pour remplacer la stratégie d’exception non gérée par défaut du Common Language Runtime. La fonction ICLRPolicyManager ::SetUnhandledExceptionPolicy est utilisée pour définir la stratégie pour les exceptions non gérées.
Voir aussi
Collaborer avec nous sur GitHub
La source de ce contenu se trouve sur GitHub, où vous pouvez également créer et examiner les problèmes et les demandes de tirage. Pour plus d’informations, consultez notre guide du contributeur.
