Application.UnhandledException Événement

public:
 virtual event UnhandledExceptionEventHandler ^ UnhandledException;

// Register
event_token UnhandledException(UnhandledExceptionEventHandler const& handler) const;

// Revoke with event_token
void UnhandledException(event_token const* cookie) const;

// Revoke with event_revoker
Application::UnhandledException_revoker UnhandledException(auto_revoke_t, UnhandledExceptionEventHandler const& handler) const;

public event UnhandledExceptionEventHandler UnhandledException;

function onUnhandledException(eventArgs) { /* Your code */ }
application.addEventListener("unhandledexception", onUnhandledException);
application.removeEventListener("unhandledexception", onUnhandledException);
- or -
application.onunhandledexception = onUnhandledException;

Public Custom Event UnhandledException As UnhandledExceptionEventHandler 

Type d'événement

Remarques

L’événement UnhandledException est utilisé pour informer l’application des exceptions rencontrées par l’infrastructure XAML ou par les Windows Runtime en général qui n’ont pas été gérées par le code d’application.

Par exemple, si l’Windows Runtime appelle du code d’application comme un gestionnaire d’événements, et si le code d’application lève une exception et ne l’intercepte pas, l’exception se propage au Windows Runtime. Le Windows Runtime déclenche ensuite l’événement UnhandledException pour notifier l’application de cette exception.

La gestion des exceptions dans un UnhandledException n’est qu’une des nombreuses techniques qui peuvent être utilisées à la fois pour le débogage et pour la gestion des exceptions d’exécution et la récupération possible. Pour plus d’informations sur l’ensemble des techniques que vous pouvez utiliser pour le débogage et la gestion des erreurs, consultez Gestion des exceptions pour en C# ou Visual Basic.

Notez que cet événement ne se déclenche que lorsqu’il n’y a plus de possibilité que le code d’application puisse intercepter une exception. Par exemple, imaginez qu’un gestionnaire d’événements d’application appelle une API Windows Runtime qui appelle à son tour un rappel. Si le code interne de l’application lève une exception et ne l’intercepte pas, l’exception se propage à travers le Windows Runtime à la couche externe du code d’application, qui a la possibilité de l’intercepter. L’événement UnhandledException est déclenché uniquement lorsqu’il n’y a plus d’occasions pour le code d’application d’intercepter une exception par le biais d’une propagation normale.

Il est également possible qu’une exception soit levée et qu’elle ne soit jamais interceptée par le code de l’application. Par exemple, si l’infrastructure XAML exécute la disposition et qu’une exception est levée, cette exception ne se propage pas dans le code d’application. Dans ce cas, l’événement UnhandledException se déclenche et ce sera la première fois qu’un code d’application est averti de l’exception.

Normalement, une fois l’événement UnhandledException déclenché, le Windows Runtime met fin à l’application car l’exception n’a pas été prise en charge. Le code de l’application a un certain contrôle sur cela : si le gestionnaire d’événements UnhandledException définit la propriété Handled des arguments d’événement sur true, dans la plupart des cas, l’application ne sera pas arrêtée. Toutefois, il n’est pas recommandé de le faire régulièrement pour plusieurs raisons :

• En règle générale, le gestionnaire d’événements UnhandledException ne dispose pas d’informations suffisantes pour savoir si la poursuite après une exception est sûre. Certaines parties du code de l’application ou du Windows Runtime peuvent être dans un état incohérent, ce qui peut entraîner des échecs ultérieurs si l’application continue d’exécuter son code.
• Le Windows Runtime considère que les exceptions rencontrées pendant certaines opérations sont irrécupérables, car le Windows Runtime lui-même est dans un état incohérent suite à ces exceptions. Pour de telles exceptions, même si le gestionnaire d’événements UnhandledException définit Handled sur true, l’application est toujours terminée.
• Les erreurs qui se produisent pendant la navigation peuvent entraîner un état où rien n’est chargé en tant que contenu et où rien n’indique à l’utilisateur que l’application est toujours en cours d’exécution.
• Pour plus d’informations sur ces points, consultez Gestion des exceptions pour en C# ou Visual Basic.

Une limitation notable est que les arguments d’événement UnhandledException ne contiennent pas autant de détails que l’exception d’origine propagée à partir du code de l’application. Dans la mesure du possible, si l’application nécessite un traitement spécifique d’une certaine exception, il est toujours préférable d’intercepter l’exception au fur et à mesure qu’elle se propage, car plus de détails seront alors disponibles. Les arguments d’événement UnhandledException exposent un objet d’exception via la propriété Exception . Toutefois, le type, le message et la trace de pile de cet objet d’exception ne sont pas garantis pour correspondre à ceux de l’exception d’origine qui a été levée. Les arguments d’événement exposent une propriété Message . Dans la plupart des cas, cela contient le message de l’exception initialement levée.

Vous ne pouvez pas connecter les gestionnaires pour UnhandledException en XAML (sur l’élément Application dans App.xaml). Vous devez attacher des gestionnaires pour UnhandledException sur l’objet Application dans le code, soit dans le constructeur, soit dans la logique d’activation.

Pour Windows 8.1 applications, les exceptions des appels de méthode asynchrone peuvent se propager en tant qu’événement UnhandledException. Cela inclut vos propres implémentations de méthode asynchrone (gestionnaires d’activation, etc.).

S’applique à

Voir aussi

• UnhandledExceptionEventArgs
• Suspending
• Resuming
• Cycle de vie de l’application
• Gestion des exceptions pour en C# ou Visual Basic
• Référence croisée : exceptions standard et codes d’erreur
• Appeler des API asynchrones en C# ou Visual Basic