Application.UnhandledException event

Occurs when an exception is raised by application code, forwarded from the native level. Applications can mark the occurrence as handled in event data.

Syntax

public event UnhandledExceptionEventHandler UnhandledException

Event information

Remarks

The UnhandledException event is used to notify the application about exceptions encountered by the XAML framework that have not been handled by application code.

For example, if the XAML framework invokes application code like an event handler, and the application code throws an exception and does not catch it, the exception will propagate back into XAML framework code. The XAML framework will then raise the UnhandledException event to notify the application of this exception.

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

The previous examples show an exception that first propagates through application code and is not caught, which results in raising the UnhandledException event. It’s also possible for an exception to be raised and never have any chance to be caught by application code. For example, if the XAML framework is performing layout and an exception is raised, this exception won’t propagate through any application code. In this case, the UnhandledException event will be raised, and this will be the first time any application code is notified about the exception.

Normally after the UnhandledException event is raised, the XAML framework terminates the application because the exception was unhandled. The application 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 application will not be terminated. However, doing so 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 XAML framework may be in an inconsistent state, which could result in subsequent failures if the application continues on.
• The XAML framework considers exceptions encountered during certain operations as un-handleable, since it is known that the XAML framework will be in an inconsistent state following these exceptions. For such exceptions, even if the UnhandledException event handler sets Handled to true, the application will still be terminated.

It’s important to be aware of several limitations of the UnhandledException event. This event is only used with exceptions encountered by the XAML framework. Exceptions encountered by other Windows Runtime components or parts of the application that are not connected to the XAML framework will not result in this event being raised. For example, if a different Windows component calls into application code and an exception is thrown and not caught, the UnhandledException event won’t be raised. If the application creates a worker thread, and then raises an exception on the worker thread, the UnhandledException event won’t be raised.

Another limitation is that the UnhandledException event arguments don’t contain as much detail as the original exception. Whenever possible, if the application requires specific processing of a certain exception, it’s always better to catch the exception as it propagates, since more detail will be available. 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 also 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.

Requirements

See also

Application

Build date: 1/31/2013