Application.UnhandledException Event

Definition

Namespace:

Windows.UI.Xaml

Occurs when an exception can be handled by app code, as forwarded from a native-level Windows Runtime error. Apps can mark the occurrence as handled in event data.

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 

Event Type

UnhandledExceptionEventHandler

Remarks

The UnhandledException event is used to notify the app about exceptions encountered by the XAML framework or by the Windows Runtime in general that have not been handled by app code.

For example, if the Windows Runtime invokes app code like an event handler, and the app code throws an exception and does not catch it, the exception will propagate back to the Windows Runtime. The Windows Runtime will then fire the UnhandledException event to notify the app of this exception.

Handling exceptions in an UnhandledException is just one of many techniques that can be used both for debugging and for run-time exception handling and possible recovery. For more info about the full set of techniques you might use for debugging and error handling, see Exception handling for in C# or Visual Basic.

Note that this event will only fire when there is no longer any possibility that app code can catch an exception. For example, imagine that an app event handler calls a Windows Runtime API that in turn invokes a callback. If the inner app code throws an exception and does not catch it, the exception will propagate through the Windows Runtime back to the outer layer of app code, which is given a chance to catch it. The UnhandledException event is fired only when there are no more opportunities for app code to catch an exception through normal propagation.

It’s also possible for an exception to be thrown and never have any chance to be caught by app code. For example, if the XAML framework is performing layout and an exception is thrown, this exception won’t propagate through any app code. In this case, the UnhandledException event fires, and this will be the first time any app code is notified about the exception.

Normally after the UnhandledException event is fired, the Windows Runtime terminates the app because the exception was unhandled. The app code has some control over this: if the UnhandledException event handler sets the Handled property of the event arguments to true, then in most cases the app will not be terminated. However, doing so routinely is not recommended for several reasons:

• Typically the UnhandledException event handler doesn’t have enough information to know whether continuing on after an exception is safe. Parts of the application code or the Windows Runtime may be in an inconsistent state, which could result in subsequent failures if the app continues running its code.
• The Windows Runtime considers exceptions encountered during certain operations as nonrecoverable, because the Windows Runtime itself will be in an inconsistent state following these exceptions. For such exceptions, even if the UnhandledException event handler sets Handled to true, the app will still be terminated.
• Errors that happen during navigation could cause a state where there's nothing loaded as content and nothing to indicate to the user that the app is still running.
• For more info on these points see Exception handling for in C# or Visual Basic.

A notable limitation is that the UnhandledException event arguments don’t contain as much detail as the original exception as propagated from app code. Whenever possible, if the app requires specific processing of a certain exception, it’s always better to catch the exception as it propagates, because more detail will be available then. The UnhandledException event arguments expose an exception object through the Exception property. However, the type, message, and stack trace of this exception object are not guaranteed to match those of the original exception that was raised. The event arguments do expose a Message property. In most cases, this will contain the message of the originally raised exception.

You can't wire handlers for UnhandledException in XAML (on the Application element in App.xaml). You must attach handlers for UnhandledException on the Application object in code, either in the constructor or in activation logic.

For Windows 8.1 apps, exceptions from async method calls can propagate as an UnhandledException event. This includes your own async method implementations (activation handlers and so on).

See also

• UnhandledExceptionEventArgs
• Suspending
• Resuming
• App lifecycle
• Exception handling for in C# or Visual Basic
• Cross-reference: Standard exceptions and error codes
• Call asynchronous APIs in C# or Visual Basic