Application.UnhandledException Evento
Definición
Importante
Parte de la información hace referencia a la versión preliminar del producto, que puede haberse modificado sustancialmente antes de lanzar la versión definitiva. Microsoft no otorga ninguna garantía, explícita o implícita, con respecto a la información proporcionada aquí.
Se produce cuando el código de la aplicación puede controlar una excepción, tal como se reenvía desde un error de Windows Runtime de nivel nativo. Las aplicaciones pueden marcar la repetición como controladas en los datos de eventos.
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 Tipo de evento
Comentarios
El evento UnhandledException se usa para notificar a la aplicación las excepciones detectadas por el marco XAML o por el Windows Runtime en general que el código de la aplicación no ha controlado.
Por ejemplo, si el Windows Runtime invoca código de aplicación como un controlador de eventos y el código de la aplicación inicia una excepción y no lo detecta, la excepción se propagará de nuevo a la Windows Runtime. A continuación, el Windows Runtime activará el evento UnhandledException para notificar a la aplicación de esta excepción.
Controlar excepciones en una excepción UnhandledException es solo una de las muchas técnicas que se pueden usar tanto para la depuración como para el control de excepciones en tiempo de ejecución y la posible recuperación. Para obtener más información sobre el conjunto completo de técnicas que puede usar para la depuración y el control de errores, consulte Control de excepciones para en C# o Visual Basic.
Tenga en cuenta que este evento solo se activará cuando ya no haya ninguna posibilidad de que el código de la aplicación pueda detectar una excepción. Por ejemplo, imagine que un controlador de eventos de aplicación llama a una API de Windows Runtime que, a su vez, invoca una devolución de llamada. Si el código interno de la aplicación produce una excepción y no la detecta, la excepción se propagará a través del Windows Runtime de nuevo a la capa externa de código de la aplicación, lo que le dará la oportunidad de detectarlo. El evento UnhandledException solo se desencadena cuando no hay más oportunidades para que el código de la aplicación detecte una excepción a través de la propagación normal.
También es posible que se produzca una excepción y nunca tenga ninguna posibilidad de ser detectada por el código de la aplicación. Por ejemplo, si el marco XAML está realizando el diseño y se produce una excepción, esta excepción no se propagará a través de ningún código de aplicación. En este caso, se desencadena el evento UnhandledException y esta será la primera vez que se notifique cualquier código de la aplicación sobre la excepción.
Normalmente después de que se desencadene el evento UnhandledException, el Windows Runtime finaliza la aplicación porque la excepción no se ha controlado. El código de la aplicación tiene algún control sobre esto: si el controlador de eventos UnhandledException establece la propiedad Handled de los argumentos de evento en true, en la mayoría de los casos la aplicación no se finalizará. Sin embargo, no se recomienda hacerlo de forma rutinaria por varias razones:
- Normalmente, el controlador de eventos UnhandledException no tiene suficiente información para saber si continuar después de una excepción es seguro. Las partes del código de la aplicación o el Windows Runtime pueden estar en un estado incoherente, lo que podría dar lugar a errores posteriores si la aplicación sigue ejecutando su código.
- El Windows Runtime considera las excepciones detectadas durante ciertas operaciones como irrecuperables, ya que el Windows Runtime en sí mismo estará en un estado incoherente después de estas excepciones. Para estas excepciones, incluso si el controlador de eventos UnhandledException establece Handled entrue, la aplicación seguirá finalizando.
- Los errores que se producen durante la navegación podrían provocar un estado en el que no hay nada cargado como contenido y nada para indicar al usuario que la aplicación todavía se está ejecutando.
- Para obtener más información sobre estos puntos, vea Control de excepciones para en C# o Visual Basic.
Una limitación notable es que los argumentos de evento UnhandledException no contienen tanto detalle como la excepción original que se propaga desde el código de la aplicación. Siempre que sea posible, si la aplicación requiere un procesamiento específico de una excepción determinada, siempre es mejor detectar la excepción a medida que se propaga, ya que habrá más detalles disponibles entonces. Los argumentos de evento UnhandledException exponen un objeto de excepción a través de la propiedad Exception . Sin embargo, no se garantiza que el tipo, el mensaje y el seguimiento de pila de este objeto de excepción coincidan con los de la excepción original que se generó. Los argumentos del evento exponen una propiedad Message . En la mayoría de los casos, esto contendrá el mensaje de la excepción generada originalmente.
No puedes conectar controladores para UnhandledException en XAML (en el elemento Application de App.xaml). Debe adjuntar controladores para UnhandledException en el objeto Application en el código, ya sea en el constructor o en la lógica de activación.
Para Windows 8.1 aplicaciones, las excepciones de las llamadas de método asincrónico pueden propagarse como un evento UnhandledException. Esto incluye sus propias implementaciones de método asincrónico (controladores de activación, etc.).