Await on a completed task same as task.Result?

There are already some good answers/comments here, but just to chime in…

There are two reasons why I prefer await over Result (or Wait). The first is that the error handling is different; await does not wrap the exception in an AggregateException. Ideally, asynchronous code should never have to deal with AggregateException at all, unless it specifically wants to.

The second reason is a little more subtle. As I describe on my blog (and in the book), Result/Wait can cause deadlocks, and can cause even more subtle deadlocks when used in an async method. So, when I’m reading through code and I see a Result or Wait, that’s an immediate warning flag. The Result/Wait is only correct if you’re absolutely sure that the task is already completed. Not only is this hard to see at a glance (in real-world code), but it’s also more brittle to code changes.

That’s not to say that Result/Wait should never be used. I follow these guidelines in my own code:

  1. Asynchronous code in an application can only use await.
  2. Asynchronous utility code (in a library) can occasionally use Result/Wait if the code really calls for it. Such usage should probably have comments.
  3. Parallel task code can use Result and Wait.

Note that (1) is by far the common case, hence my tendency to use await everywhere and treat the other cases as exceptions to the general rule.

Leave a Comment