Événement System.AppDomain.UnhandledException

Cet article vous offre des remarques complémentaires à la documentation de référence pour cette API.

L’événement UnhandledException fournit une notification d’exceptions non interceptables. Elle permet à l’application de consigner des informations sur l’exception avant que le gestionnaire système par défaut signale l’exception à l’utilisateur et termine l’application. Si des informations suffisantes sur l’état de l’application sont disponibles, d’autres actions peuvent être effectuées, telles que l’enregistrement des données du programme pour une récupération ultérieure. La prudence est recommandée, car les données du programme peuvent être endommagées lorsque les exceptions ne sont pas gérées. Le gestionnaire s’exécute également pendant que les verrous sont conservés lorsque l’exception a été levée. Vous devez donc veiller à éviter d’attendre d’autres ressources susceptibles d’introduire des interblocages.

Cet événement peut être géré dans n’importe quel domaine d’application. Toutefois, l’événement n’est pas nécessairement déclenché dans le domaine d’application où l’exception s’est produite. Une exception n’est pas gérée uniquement si l’ensemble de la pile du thread a été déwound sans trouver de gestionnaire d’exceptions applicable. Par conséquent, le premier endroit où l’événement peut être déclenché se trouve dans le domaine d’application où provient le thread.

Si l’événement UnhandledException est géré dans le domaine d’application par défaut, il est déclenché pour toute exception non gérée dans n’importe quel thread, quel que soit le domaine d’application dans lequel le thread a démarré. Si le thread a démarré dans un domaine d’application pour lequel un gestionnaire UnhandledExceptiond’événements est associé, l’événement est déclenché dans ce domaine d’application. Si ce domaine d’application n’est pas le domaine d’application par défaut et qu’il existe également un gestionnaire d’événements dans le domaine d’application par défaut, l’événement est déclenché dans les deux domaines d’application.

Par exemple, supposons qu’un thread démarre dans le domaine d’application « AD1 », appelle une méthode dans le domaine d’application « AD2 » et, à partir de là, appelle une méthode dans le domaine d’application « AD3 », où elle lève une exception. Le premier domaine d’application dans lequel l’événement UnhandledException peut être déclenché est « AD1 ». Si ce domaine d’application n’est pas le domaine d’application par défaut, l’événement peut également être déclenché dans le domaine d’application par défaut.

Remarque

Le Common Language Runtime interrompt les interruptions de thread pendant l’exécution des gestionnaires d’événements pour l’événement UnhandledException .

Si le gestionnaire d’événements a un ReliabilityContractAttribute attribut avec les indicateurs appropriés, le gestionnaire d’événements est traité comme une région d’exécution contrainte.

À compter de .NET Framework 4, cet événement n’est pas déclenché pour les exceptions qui endommagent l’état du processus, telles que les dépassements de capacité de pile ou les violations d’accès, sauf si le gestionnaire d’événements est critique pour la sécurité et a l’attribut HandleProcessCorruptedStateExceptionsAttribute .

Pour inscrire un gestionnaire d’événements pour cet événement, vous devez disposer des autorisations requises, ou une SecurityException exception est levée.

Pour plus d'informations sur la gestion des événements, voir gestion et déclenchement d’événements.

Autres événements pour les exceptions non gérées

Pour certains modèles d’application, l’événement UnhandledException peut être préempté par d’autres événements si l’exception non gérée se produit dans le thread d’application principal.

Dans les applications qui utilisent Windows Forms, les exceptions non gérées dans le thread d’application principal entraînent le levée de l’événement Application.ThreadException . Si cet événement est géré, le comportement par défaut est que l’exception non gérée n’arrête pas l’application, bien que l’application soit laissée dans un état inconnu. Dans ce cas, l’événement UnhandledException n’est pas déclenché. Ce comportement peut être modifié à l’aide du fichier de configuration de l’application ou à l’aide de la Application.SetUnhandledExceptionMode méthode pour modifier le mode UnhandledExceptionMode.ThrowException avant que le ThreadException gestionnaire d’événements soit branché. Cela s’applique uniquement au thread d’application principal. L’événement UnhandledException est déclenché pour les exceptions non gérées levées dans d’autres threads.

L’infrastructure d’application Visual Basic fournit un autre événement pour les exceptions non gérées dans le thread d’application principal, l’événement WindowsFormsApplicationBase.UnhandledException . Cet événement a un objet d’arguments d’événement portant le même nom que l’objet d’arguments d’événement utilisé par AppDomain.UnhandledException, mais avec des propriétés différentes. En particulier, cet objet arguments d’événement a une ExitApplication propriété qui permet à l’application de continuer à s’exécuter, en ignorant l’exception non gérée (et en laissant l’application dans un état inconnu). Dans ce cas, l’événement AppDomain.UnhandledException n’est pas déclenché.