c# - 在签名中包含异步(在正文中没有等待)对程序流程有什么影响？

Question

一般问题

我刚刚追踪到一个奇怪的行为，即方法签名中缺少 async 修饰符。有了它，我得到了预期的行为，但没有它，我的程序表现得很奇怪。

问题是，方法的主体是完全同步的:看不到一个 await。我什至(如预期的那样)收到编译器警告 1998:

This async method lacks 'await' operators and will run synchronously. Consider using the 'await' operator to await non-blocking API calls, or 'await Task.Run(...)' to do CPU-bound work on a background thread.

然后诱惑是将其删除。 (我的意思是，编译器基本上是在告诉我这样做!)当我删除它时，我开始可靠地遇到意外行为。

我的问题是:当没有等待时，async 到底在做什么？

---

背景/细节

我不认为我的应用程序的细节与我渴望理解的基本解释相关，但我将其包含在这里以提供一些 flavor ...

我正在开发的程序使用来自服务总线的消息。我的方法的签名是:

public async Task<BrokeredMessage> ProcessMessageAsync(BrokeredMessage inMessage) 

历史背景:我最初是从同事写的类似程序中借用的，方法名称(暗示异步操作)是接口(interface)实现的一部分。

当我删除 async 修饰符时，我遇到的奇怪行为是方法的主体已执行，但消息返回为无法传递。一个有趣的结果是，我最终会为每次重试尝试处理消息。 (我很幸运，这是一个小数字!)

---

更新

正如 Skeet 先生所指出的，重要的是，尽管签名 promise 返回类型为 Task 的值，但我的方法实际上返回了 null。

Answer 1

My question is: what is async really doing when there isn't an await?

就可观察的行为而言:

• 如警告所述，代码仍将同步运行
• 结果(包括抛出的任何异常)将包含在 Task 中

在实现方面，编译器会生成一个状态机来处理所有的异步性。不过，这不应该改变任何其他行为。

我无法立即想到您会看到此消息行为的任何原因，除非由于异常处理而有所不同。如果调用代码正在捕获异常但忽略了错误的任务(反之亦然)，这肯定可以解释差异。我的第一个诊断步骤是添加一些日志记录，以查看方法确实是否成功完成，或者是否在某处抛出异常。

现在您已经声明要返回 null ，从调用者的角度来看，这是一个明显的区别:返回 null 的方法之间存在巨大差异。 Task<BrokeredMessage> 的值，以及一个返回 Task<BrokeredMessage> 的方法用null其值(value)Result属性(property)。也许调用者正在取消引用返回值，并且 NullReferenceException被扔了吗？

如果是这种情况，您的第一个停靠点应该是找出您之前无法看到该异常的原因 - 它表明缺少一些日志记录。然后你可以通过改变这个来修复它:

return null;

到

return Task.FromResult<BrokeredMesage>(null);