Await, Catch, and Finally in C# 6
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
In this article, I'll talk about one of the new features in C# 6 that surprised many people because they thought it was already implemented. That added feature is the await keyword in either a catch clause, or a finally clause of an async method.
In the 5.0 version of the C# compiler, the language disallowed await expressions in catch and finally clauses, and that limitation actually caused quite a few issues. Most applications include logging or similar features in catch clauses. In distributed systems, logging may be an async operation. And often we might perform some cleanup work (which may be async) in a finally clause.
Consider this example:
public async Task DoWorkAsync()
{
try
{
var items = DownloadSitesAsync(allSites);
allResults.AddRange(await items);
} catch(Exception e)
{
await LogResultAsync("Site download failed", e);
}
}
The code above indicates that my LogResult method is an asynchronous method, returning a task. In C# 5, you would either wait synchronously for the LogResult task to complete, or just "fire and forget" the log call.
The developer who wrote LogResult() indicates that this method requires access to an asynchronous resource by returning a Task, following the convention of ending the method in Async. Waiting (synchronously) for this method's return will block the application and affect responsiveness, so forcing that is not a good option.
The "fire and forget" option also isn't great. It starts a task, but doesn't monitor that task for successful completion. If errors are generated from LogResultAsync and the task faults, you can't notice that problem and do something about it. (Actually, if your logging infrastructure is generating exceptions, I'm not sure how you report it. But that's a story for another day.)
You might be releasing resources in the finally clause of your method, and those methods could also be Task-returning methods. With C# 6, you can also await those tasks:
public async Task WorkWithAsyncResource()
{
var resource = await AcquireResourceAsync();
try
{
resource.SetState(config);
await resource.StartWorkAsync();
} finally
{
await resource.ReleaseResourceAsync();
}
}
In previous versions of C#, the code above had all the same issues I highlighted in the first example. There is no easy way to monitor the progress of that task started in the finally clause. You can either wait synchronously, or simply ignore it. The same issues apply that I mentioned in the first example. Here, though, the resource needs to be freed in both successful and exceptional cases. It was much harder to write clean code when you were unable to await in a finally or a catch clause. We might even write some out-of-band logic to store the Task in a member variable or another object, and monitor tasks there.
The addition of await support in catch and finally clauses means we can use the same async idioms in all our code. No more unsightly workarounds. The implementation is quite complicated. But that implementation is done by the compiler, and it doesn't impact the readability or maintainability of our code. We write much clearer, cleaner logic, and the compiler handles the asynchronous nature of the libraries we use.
How Exceptions Propagate When Awaiting
When I first saw this feature, I was somewhat taken aback. I was quite worried about how and when exceptions would propagate when they were thrown by faulted tasks that were awaited in catch or finally clauses. I wondered when those exceptions would surface in the program. The answer is really quite simple: They're observed in a way that's a natural complement to the behavior for synchronous methods.
In synchronous code, you can call methods in catch clauses or finally clauses that throw exceptions. When that happens, the exception is thrown immediately. If the new exception is thrown when another exception is active, the new exception effectively hides the previous exception. The newly thrown exception is now the active exception, and a new stack-unwinding process begins.
Consider this block of code:
var s = new Service();
try
{
s.Work(true);
} catch (Exception e)
{
s.Report(true);
}
finally
{
s.Cleanup();
}
Imagine that s.Work() throws an InvalidOperationException. The code next enters the catch clause. Well, suppose s.Report() tries to access an uninitialized member and throws a NullReferenceException. The catch clause exits, and a new stack-unwinding process begins. The finally clause begins execution. s.Cleanup() can also throw an exception, so let's imagine that it throws a FileNotFoundException. That exception replaces the NullReferenceException, which itself replaced the InvalidOperationException. The only exception that can be observed higher up the call stack is the FileNotFoundException.
Let's compare that description with this async code:
public async Task WorkWithAsyncResource()
{
var resource = await AcquireResourceAsync();
try
{
resource.SetState(config);
await resource.StartWorkAsync();
} catch (Exception e)
{
await LogResultAsync("working with resource fails", e);
} finally
{
await resource.ReleaseResourceAsync();
}
}
If an exception is thrown by SetState or StartWorkAsync, execution enters the catch clause. If the LogResultAsync() method throws an exception, that exception replaces the exception that had been thrown from the code above it. The finally clause is yet to execute, and that execution begins. If ReleaseResourceAsync() also throws an exception, that exception can be observed by awaiting the task returned by WorkWithAsyncResource.
The end result is that any code awaiting that task would be able to observe the exception thrown from the finally clause. The other exceptions could no longer be observed.
Some Initial Guidance on using await with catch and finally
This is the only new feature in C# 6 that caused me to search through existing code and add await expressions in catch or finally clauses. I'd usually find a synchronous wait in those cases, and the change will create better responsiveness. In cases where an async method was called and the task was never awaited, adding await improves processing. In cases where a custom implementation of some other workaround monitored tasks initiated from catch or finally clauses, I can happily remove that code, relying on the compiler to generate the needed infrastructure.
I've also looked for async methods that were intended to be called from catch clauses. A few were async void methods, which I converted to Task-returning async methods, and await those tasks.
Many developers may have assumed this feature already existed. But now it enables us to use the correct idioms for async programming throughout our code. It's worth converting existing code to make use of the new idioms.