Significance of declaring a WPF event handler as 'async' in C# 5
You may find my async/await intro helpful.
An async
method is re-written by the compiler to support the await
operator. Every async
method starts out synchronous (in this case, on the UI thread) until it await
s some operation (that is not already completed).
By default, the context is saved, and when the operation completes, the rest of the method is scheduled to execute in that context. The "context" here is SynchronizationContext.Current
unless it is null
, in which case it is TaskScheduler.Current
. As Drew pointed out, WPF provides a DispatcherSynchronizationContext
which is tied to the WPF Dispatcher
.
Regarding error handling:
When you await
a Task
inside a WPF async void
event handler, the error handling goes like this:
- The
Task
completes with an error. The exception is wrapped into anAggregateException
, like allTask
errors. - The
await
operator sees that theTask
completed with an error. It unwraps the original exception and re-throws it, preserving the original stack trace. - The
async void
method builder catches the exception escaping from anasync void
method and passes it to theSynchronizationContext
that was active when theasync void
method started executing (in this case, the same WPF context). - The exception is raised (with the original stack trace, and without any annoying
AggregateException
wrapping) on theDispatcher
.
This is rather convoluted, but the intent is to have exceptions raised from async
event handlers be practically the same as exceptions raised from regular event handlers.
A partial answer. From MSDN:
An async method that has a void return type can’t be awaited, and the caller of a void-returning method can't catch any exceptions that the method throws.
So any errors would only be available via the TaskScheduler
.
Also, there's nothing XAML-specific going on with the event handler registration. It could have been done in code:
this.button.Click += OnButtonClick;
Or even as an async lambda:
this.button.Click += async (s,e) => { ... };
As for safety of UI updates after an await
, it seems that the continuation is executed within SynchronisationContext.Current
, which is set per thread. In WPF, this is a DispatcherSynchronisationContext
that's coupled to the WPF Dispatcher
that pumped the event in the first place.