Await in Catch and Finally

This is just a brief note to publicize a coming improvement to the async language support.

Visual Studio “14” is currently in CTP, and is available for download. One of the primary advantages of this release is the new Roslyn-based compilers.

Note that the “14” in the name is the version number, not the year of release. In other words, the CTP is for “Visual Studio 14”, not “Visual Studio 2014”. If I had to guess, I would say that this CTP will probably become “Visual Studio 2015”.

With the new compilers, changes to the C# language (e.g., async/await) are easier than they used to be. One improvement that is coming is the use of await in catch and finally blocks. This enables your error-handling/cleanup code to be asynchronous without awkward code mangling.

For example, let’s say that you want to (asynchronously) log an exception in one of your async methods. The natural way to write this is:

try
{
  await OperationThatMayThrowAsync();
}
catch (ExpectedException ex)
{
  await MyLogger.LogAsync(ex);
}

And this natural code works fine in Visual Studio “14”. However, the currently-released Visual Studio 2013 does not support await in a catch, so you would have to keep some kind of “error flag” and move the actual error handling logic outside the catch block:

ExpectedException exception = null;
try
{
  await OperationThatMayThrowAsync();
}
catch (ExpectedException ex)
{
  exception = ex;
}
if (exception != null)
  await MyLogger.LogAsync(exception);

This is only a simple example; in real-world code, this can get ugly rather quickly!

Fortunately, it looks like the next version of Visual Studio will fix this by allowing await within catch and finally blocks. I’ve tested this out with the Visual Studio “14” CTP, and it does work!

This blog post is describing technology currently in preview (CTP). The final product may be different.