對於已完成的任務，什麼時候應該使用'await”而不是'Task.Result”？

await 與 Task.Result 已完成任務：最佳實踐

《C# 並發手冊》示範了處理已完成任務的模式：

<code class="language-csharp">var completedTask = await Task.WhenAny(downloadTask, timeoutTask);
if (completedTask == timeoutTask)
  return null;
return await downloadTask;</code>

此程式碼使用 Task.WhenAny 來決定 downloadTask（httpclient.GetStringAsync 呼叫）是否在 timeoutTask（Task.Delay 操作）之前完成。

為什麼使用 await downloadTask 而不是簡單地回傳 downloadTask.Result？ 原因很關鍵：

異常處理：

• await 避免了 AggregateException 的複雜性。 Task.Result 或 Task.Wait() 將異常包裹在 AggregateException 中，掩蓋了根本原因。 理想情況下，非同步程式碼應該直接處理異常，從而使 await 成為更乾淨的解決方案。

避免死鎖：

• 在非同步方法中使用 Task.Result 或 Task.Wait() 可能會導致死鎖。 await 專為非同步情境而設計，可防止這種常見陷阱。

最佳實務摘要：

• 在非同步應用程式程式碼中優先使用await，以實現更好的異常處理和死鎖預防。
• 雖然 Task.Result 或 Task.Wait() 在實用程式程式碼中可能是可以接受的（有明確的註解解釋其基本原理），但通常最好避免使用。
• Task.Result 和 Task.Wait() 可以考慮用於同步阻塞是可以接受和理解的平行任務場景。

以上是對於已完成的任務，什麼時候應該使用'await”而不是'Task.Result”？的詳細內容。更多資訊請關注PHP中文網其他相關文章！