Am I right to ignore the compiler warning for lacking await for this async call?

Question

I have the following method that is triggered when an exception occurs in a part of my Metro application

void Model_ExceptionOccured(Exception ex)
{
    var dlg = new Windows.UI.Popups.MessageDialog("An exception occured during verification: " + ex.Message, "Exception");
    dlg.ShowAsync();
}

The 'dlg.ShowAsync()'-call is asynchronous, but I don't care to wait for the result. The compiler generates a warning for it though:

Because this call is not awaited, execution of the current method continues before the call is completed. Consider applying the 'await' operator to the result of the call.

Should I care? Is there any reason I should add the await keyword, other than to get rid of the warning?

Solution 1

According to the below link, the answer given by alexm is not correct. Exceptions thrown during an async call that is not awaited will be lost. To get rid of this warning, you should assign the Task return value of the async call to a variable. This ensures you have access to any exceptions thrown, which will be indicated in the return value.

http://msdn.microsoft.com/en-us/library/hh965065(v=vs.110).aspx (VB.NET)

http://msdn.microsoft.com/en-us/library/hh873131.aspx (C#)

Solution 2

The issue with that is if the code in dlg.ShowAsync(); throws an exception it will be left unhandled and will be re-thrown later by the Finalizer thread potentially causing your program termination.

What happens in reality depends on .NET exception policy

This article on MSDN mentions this:

If you do not wait on a task that propagates an exception, or access its Exception property, the exception is escalated according to the .NET exception policy when the task is garbage-collected.

When VS 2012 was eventually shipped, the default policy for unhandled task exceptions changed from terminating process to ignore exception.

Comments

[alexm]

In VS2012 they changed the default policy for unobserved task exceptions. Default behavior was to terminate the process.

[alexm]

the link you provided shows VB-specific error. Do you have similar reference for C#?

[ruffin]

From the link: "In most cases, that behavior isn't what you expect. Usually other aspects of the calling method depend on the results of the call or, minimally, the called method is expected to complete before you return from the method that contains the call." That makes some sense, though it seems if you wrap ShowAsync in a try block and take the link's suggestion to catch with a task (Task showAsyncResult = dlg.ShowAsync();), you're still fine, if not best practicing?

[Mathieson]

You can use the task Exception and ContinueWith for the same effect - it seems like you're reinventing the wheel, especially introducing polling onto async methods.