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:
- Asynchronous code in an application can only use
await
.
- Asynchronous utility code (in a library) can occasionally use
Result
/Wait
if the code really calls for it. Such usage should probably have comments.
- 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.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…