Partager via

Application.UnhandledException Événement

  • Référence

Définition

Espace de noms:
Microsoft.UI.Xaml
Modifier

Se produit lorsqu’une exception peut être gérée par le code d’application, comme transféré à partir d’une erreur de Windows Runtime de niveau natif. Les applications peuvent marquer l’occurrence comme gérée dans les données d’é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

UnhandledExceptionEventHandler

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 de l’application.

Par exemple, si le Windows Runtime appelle du code d’application comme un gestionnaire d’événements, et que le code d’application lève une exception et ne l’intercepte pas, l’exception se propage à nouveau vers le 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 n’est qu’une des nombreuses techniques qui peuvent être utilisées à la fois pour le débogage et pour la gestion des exceptions au moment de UnhandledException l’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 (Guide de programmation C#).

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 UnhandledException gestionnaire d’événements 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 UnhandledException gestionnaire d’événements ne dispose pas d’informations suffisantes pour savoir si la poursuite après une exception est sécurisée. Certaines parties du code de l’application ou de l’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 au cours de 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 UnhandledException gestionnaire d’événements définit Handled sur true, l’application sera 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 (Guide de programmation C#).

Une limitation notable est que les UnhandledException arguments d’événement ne contiennent pas autant de détails que l’exception d’origine propagée à partir du code d’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 UnhandledException arguments d’événement 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.

S’applique à

Voir aussi