Exceptions dans les threads managés

  • Article

Le common language runtime permet à la plupart des exceptions non prises en charge dans les threads de poursuivre naturellement. Dans la plupart des cas, cela signifie que l’exception non prise en charge provoque l’arrêt de l’application. Le common language runtime représente une protection pour certaines exceptions non prises en charge qui sont 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 levant 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, elle arrête le thread, mais le common language runtime n’autorise pas l’exception à poursuivre.

Si ces exceptions ne sont pas prises en charge dans le thread principal ou dans les threads qui sont entrés dans le runtime à partir de code non managé, elles se poursuivent normalement, ce qui entraîne l’arrêt de l’application.

Notes

Il est possible que le runtime lève une exception non prise en charge avant que du code managé ait pu installer un gestionnaire d’exceptions. Bien que le code managé n’ait pas eu la possibilité de traiter cette exception, elle est autorisée à poursuivre naturellement.

Mettre en lumière des problèmes de threads au cours du développement

Lorsque les threads sont autorisés à s’interrompre de façon silencieuse, sans arrêter l’application, de graves problèmes de programmation risquent de passer inaperçus. Il s’agit d’un problème particulier pour les services et autres applications qui s’exécutent sur de longues périodes. Au fur et à mesure des échecs de threads, le programme s’endommage progressivement. L’application risque de voir ses performances se dégrader ou de ne plus répondre.

Le fait d’autoriser les exceptions non prises en charge dans les threads à poursuivre naturellement, jusqu’à ce que le système d’exploitation arrête le programme, expose à de tels problèmes lors du développement et des tests. Les rapports d’erreurs sur les arrêts du programme prennent en charge le débogage.

Remplacement de l’hôte

Un hôte non managé peut utiliser l’interface ICLRPolicyManager dans l’API d’hébergement pour remplacer la stratégie d’exceptions non prises en charge par défaut du common language runtime. La fonction ICLRPolicyManager::SetUnhandledExceptionPolicy est utilisée pour définir la stratégie des exceptions non prises en charge .

Voir aussi