为什么 C# 编译器处理空异步任务方法与仅返回 Task.CompletedTask 不同？

Question

Hello,

Edit: the post was edited to not use empty methods to be more clear about what I want to know.

Is there a reason why the C# compile does not compile a async Task method without using await to return Task.CompletedTask ?

Sometimes it is necessary to implement a method that returns a Task but it is not using await .

I am wondering if there is a reason why the generated IL code is so different between that two methods:

public async Task DoNothing()
{
    Console.WriteLine("nothing");
}

public Task DoNothing()
{
    Console.WriteLine("nothing");
    return Task.CompletedTask;
}

I created two Fiddles where the generated IL code can be viewed.
async Task : https://dotnetfiddle.net/UQuJUh
Task.CompletedTask : https://dotnetfiddle.net/eRr4i1

So is there a reason why the compiler does not optimize the code to handle both cases the same way? Thank you.

Answer 1

There is a significant difference in the way exceptions are handled in those two pieces of code, which are therefore not equivalent :

public async Task DoNothing()
{
    Console.WriteLine("nothing");
}

In the case that Console.WriteLine raised an exception, the exception is actually internally caught and stored inside the resulting Task , indicated by Task.IsFaulted . The exception is only actually "thrown" when you use await on the task.

public Task DoNothing()
{
    Console.WriteLine("nothing");
    return Task.CompletedTask;
}

This case however is fully synchronous; the potential exception from Console.WriteLine would be raised even before any task could be returned or processed. I'd argue this is actually a bit less safe than the first option, since this behaviour might be unexpected. Iterators show similar behaviour for the difference between yield break; and return Array.Empty<object>(); .

Now your question originally asked about an actually empty method. Well, it could be the case that the method is not actually empty; it may contain breakpoints in debug mode, injected code or perhaps auto-generated checks for the arguments, in the future. Even the empty try block is still generated for an empty method body:

  .try
  {
    IL_0000:  leave.s    IL_0019
  }  // end .try
  catch [mscorlib]System.Exception 
  {

Now I can imagine an exception in generating async method could be added to the compiler for the case of a truly empty method, but it would only complicate the code, for no (arguably) real gain. There might be a point of having an empty async method (such as to give other programmers who might want to implement it in a future a hint), but then you don't need to care about performance that much to warrant such an optimization (and you have a trivial solution anyway).

(Interesting side note: C# 11 might introduce automatic raising of ArgumentNullException from parameters marked with !! . At this time, the exception is actually raised outside of the async /iterator method's code, immediately after the call, so it could be argued that the method body, or what becomes of it, is still, technically, empty.)