.NET Core學習筆記（3）——async/await中的Exception處理
在寫了很多年.NET程式之後，年長的猿類在面對非同步程式設計時，仍不時會犯下致命錯誤，乃至被拖出去殺了祭天。本篇就async/await中的Exception處理進行討論，為種族的繁衍生息做出貢獻……
處理async/await中的Exception，最致命的莫過於想抓的Exception抓不到，程式崩的莫名其妙，連日誌都沒記下來，沒法定位錯誤。讓我們來看以下程式碼：
private async void SomethingWrongAsync()
{
await Task.Delay(100);
throw new InvalidOperationException();
}
public void SomethingWrongCannotCatch()
{
try
{
SomethingWrongAsync();
}
catch (Exception)
{
// Sometimes we write log here, but the exception is never caught!
throw;
}
}SomethingWrongAsync是一個標準的async方法。在這個方法中，我們主動丟擲了InvalidOperationException。我們在方法SomethingWrongCannotCatch中呼叫了SomethingWrongAsync。但是非常遺憾，這裡的try catch無法捕捉到InvalidOperationException。
包含以上程式碼的Sample工程是一個WPF程式，程式碼連結：
https://github.com/manupstairs/AsyncAwaitPractice
在測試之前，我們可以在throw那一行打個斷點，F5起來後，點選MainWindow的SomethingWrongCannotCatch按鈕。非常遺憾程式崩了，並且沒有進入斷點。
這意味著如果我們想在這個try catch裡對Exception做出處理，甚至僅僅記錄日誌，都是一個不可能完成的任務。如果我們在WPF工程的App.xaml.cs裡新增如下程式碼:
public partial class App : Application
{
public App()
{
this.DispatcherUnhandledException += (sender, e) =>
{
Debug.WriteLine(e);
};
}
}確實是可以捕捉到這個異常，不過在DispatcherUnhandledException事件中，我們已經錯過了處理Exception的時機，能做的也僅僅是記錄日誌。這並不是正確的處理異常的方式。
讓我們來看另一段稍有不同的程式碼：
private async Task TaskWrongAsync()
{
await Task.Delay(100);
throw new InvalidOperationException();
}
public void TaskWrongWithNothing()
{
try
{
TaskWrongAsync();
}
catch (Exception)
{
// Sometimes we write log here, but the exception is never caught!
throw;
}
}
除方法名外，程式碼僅做了些微的改變，throw new InvalidOperationException的TaskWrongAsync方法，把返回型別從void改為了Task。按F5執行，點選MainWindow的按鈕TaskWrongWithNothing。似乎什麼也沒有發生，即使DispatcherUnhandledException事件也無法捕獲任何異常。在真實的專案中，很可能TaskWrongAsync已經破壞了程式的狀態，卻沒有被任何人察覺。
其實Visual Studio已經嗅出了程式碼的壞味道，每一個Warning都可能是致命的。在這裡我們按照智慧提示修復這個Warning，再重新除錯看看。
public async void TaskWrongButCatch()
{
try
{
await TaskWrongAsync();
}
catch (Exception)
{
throw;
}
}
通過TaskWrongButCatch方法，我們可以在catch中成功捕獲InvalidOperationException。接著在被我們throw後，也可以成功觸發DispatcherUnhandledException事件。
接下來對這三種寫法的區別做出一些解釋，通常async Task方法是將Exception置於Task物件中，在Exception發生時，Task的狀態將變成Faulted，然後在執行await操作時，由Task將Exception拋回給呼叫執行緒，所以我們可以通過try catch來捕獲。
而第一種async void方法，因為返回值沒有Task，無法通過await操作將Exception拋回撥用執行緒。async void方法中的Exception將在SynchronizationContext 上丟擲，這種情況下無法在async void方法的外部捕捉到Exception。
正確的做法是，避免寫async void方法，而是通過Task來返回。只有在作為event處理方法時，才應該編寫async void的方法。
第二個例子中我們犯下了更為可怕的錯誤，Exception被完全掩蓋了。第一個例子中雖然我們不能在async void方法外部捕獲Exception，但實際Exception對WPF程式而言是可見的，可以通過DispatcherUnhandledException觀察到。而有了Task卻不await，程式不知道Task何時結束。這個Exception會一直到Task被請求結果時，才會被丟擲來。我們可以試試如下程式碼，異常會在請求Result時被丟擲。
static void Main(string[] args)
{
new Program().TaskIntWrongWithResult();
Console.ReadKey();
}
private async Task<int> TaskIntWrongAsync()
{
await Task.Delay(100);
throw new InvalidOperationException();
}
public void TaskIntWrongWithResult()
{
var result = TaskIntWrongAsync().Result;
Console.WriteLine(result);
}
相對於DispatcherUnhandledException事件，我們確實也可以通過TaskScheduler.UnobservedTaskException事件來檢測Task中未被丟擲的Exception。但在這裡我們能做的僅僅是記錄日誌，實際絕對不推薦不給Task應用await關鍵字。
綜上所述，async/await非同步方法的Exception處理應遵循如下原則：
• 儘量避免async void，而採用async Task方式。
• 應用await給每一個Task返回值。
• 使用async void 作為非同步方法鏈的終結點時，加上try…catch。
• 同理可以推測出對於async lamdba，不要使用Action委託型別，而應該始終使用Func<Task>這樣有Task返回的委託型別。
• 通過TaskScheduler.UnobservedTaskException事件來檢測漏網之魚。
本篇所有程式碼見Github：
https://github.com/manupstairs/AsyncAwaitPractice