Taskクラスとasync-awaitを使用して非同期処理を記述する場合の、例外にまつわるあれこれをまとめました。
概要：
- 表面上は殆ど変らない
- 現実の動作
- タスクコンテキストとスレッドコンテキスト
- スタックウォーク
- 処理されない例外
この記事は、非同期処理と例外処理について、多少難易度の高い話題を含みます。もし、もっと基本的な記述方法や、安全に例外を処理する方法を知りたい場合は、この記事をお勧めします: 「.NET非同期処理で例外を安全に対処する」
この記事の前に、非同期処理の基本を扱った記事もあります: 「.NET非同期処理(async-await)を制御する、様々な方法」
非同期処理中に発生する例外の捕捉
非同期処理中に発生する例外を捕捉する方法は、一般的な例外の捕捉とほとんど変わりません。
// 指定されたURLからHTMLコンテンツをダウンロードする
public static async Task<XElement> StartFetchContentAsync(Uri url)
{
using (var httpClient = new HttpClient())
{
try
{
// HTTP GETでURLに非同期的に要求する
using (var stream = await httpClient.GetStreamAsync(url))
{
// （パース）
return SgmlReader.ParseXElement(stream);
}
}
// 非同期処理中（又は同期処理中）に発生した例外を捕捉
catch (Exception ex)
{
// 何かエラー処理
logger_.WriteLog(ex.Message);
// 再スロー
throw;
}
}
}
上記のコードにより：
- GetStreamAsync非同期メソッドの完了待機中（await）に発生した例外の捕捉
- それ以外の例外（例：SgmlReaderのパース）の捕捉
の両方とも、catch構文で例外を捕捉出来ます。
上記の例では示しませんが、C#5.0では、catchブロック中（又はfinally）で更に非同期メソッドを呼び出して待機（await）することは出来ません。C#6.0では可能です。
Task.WhenAllを使って非同期処理を集約している場合、一度に複数の例外が発生するかもしれないため、発生した例外は「AggregateException」クラスに内包されてスローされます。
// 指定されたURL群からHTMLコンテンツをダウンロードする
public static async Task<XElement[]> StartFetchContentsAsync(IEnumerable<Uri> urls)
{
try
{
return await Task.WhenAll(
urls.Select(async url =>
{
using (var httpClient = new HttpClient())
{
// HTTP GETでURLに非同期的に要求する
using (var stream = await httpClient.GetStreamAsync(url))
{
// （パース）
return SgmlReader.ParseXElement(stream);
}
}
}));
}
// Task.WhenAllで発生した例外を捕捉
catch (AggregateException ex)
{
// 何かエラー処理
ex.InnerExceptions.ForEach(iex => logger_.WriteLog(iex.Message));
// 再スロー
throw;
}
}
非同期処理の遷移
上記のように、非同期メソッドを呼び出して例外を処理するコードを書いても、表面上は同期メソッド呼び出しと殆ど変りません。また、実際に考慮すべき事も殆ど変りません。しかし、内部で発生している例外がどのように処理されているのかという点では、かなり異なります。
以下の図を見て下さい：
（なお、まるでこれがHttpClientの実装であるかのように書いていますが、実際のHttpClientは別の手法で実現している可能性があります）
これは、非同期メソッドではなく、同期メソッドでの例外のフローです（疑似的に、HttpClientに「GetStream」という同期メソッドがあると仮定して書いています。実際にはありません）。
GetStreamを呼び出したものの、指定されたURLに接続出来なかったり、HTTPサーバーがエラーを返すなどした場合、メソッド内で例外がスローされます。それはそのまま呼び出し元のcatchブロックでキャッチされます。当たり前ですが、この時の呼び出し元スレッドの実行パスは、赤い矢印で図示した通りの経路をたどります。
では、非同期メソッドを呼び出した場合はどうなるでしょうか？
まず、GetStreamAsyncは非同期メソッドなので、異なる実行コンテキスト上で接続処理が行われます。「実行コンテキスト」とは、今はまだ「ワーカースレッド」と言うように読み替えて構いません。そして、実行コンテキストが異なるという事は、呼び出し元スレッドの実行パスは、接続処理を行っているコンテキストとは別に、平行して処理が可能である事を意味します。
この例では、呼び出し元のスレッドがGetStreamAsyncから抜けた（Task<Stream>の戻り値を得る）際に、すぐに「await」を実行 – つまり非同期的に待機します。その間、まだ接続処理は別のコンテキスト（ワーカースレッド）で実行中です。ここで、接続に失敗するなどして例外が発生したとします。
先ほど、実行コンテキストはワーカースレッドと読み替えて良いという話をしました。そのため、接続処理で発生した例外は、「そのスレッドコンテキスト内のcatchブロック」で捕捉されます。図ではそれを疑似的に示しましたが、これでは、ワーカースレッド上では例外を捕捉出来ても、呼び出し元では捕捉出来ない事になります。
従来のThreadクラスによるワーカースレッド処理では、ワーカースレッドで発生した例外を、どうやって元のスレッドに通知するのかという事も、設計者が考慮する必要がありました。しかし、Taskベースの非同期処理では、例外を通知するのはTaskクラスの役割となっていて、一貫した操作が可能となっています。
「.NET非同期処理(async-await)を制御する、様々な方法」でも書きましたが、能動的な方法で通知するのであれば、「TaskCompletionSourceクラス」を使えば、SetExceptionメソッドを使用して、呼び出し元のスレッドに通知する事が出来ます。
余談ですが、仮に接続処理が「Task.Runメソッド」によって実行されていた場合、スローされた例外は自動的にRunメソッドによって捕捉され、呼び出し元のスレッドに通知されます。
実行コンテキストとは
非同期メソッド内の非同期的な処理を行う主体を、「ワーカースレッド」ではなく「実行コンテキスト」という抽象的な呼び方をしました。上記の説明の通り、非同期的な処理が実際にワーカースレッドで実現されているのか、又はそれ以外のなんらかの方法で実現されているのかは、メソッドの呼び出し元からは知る由もなく、知る必要のない、実装の詳細です（現実には把握したい場合もあるかもしれませんが）。
ワーカースレッドでなければ、どうやって非同期処理を実現するのでしょうか？ 一例を挙げるなら、Win32 APIでは一般的な「コールバック」です。Win32では伝統的に、処理の完了や失敗をコールバックで通知する事が多いのです。これは、Windowsのカーネルモード内部奥深く、デバイスドライバーが発する完了のタイミングの処理から、鮭が川を上ってくるように「逆方向」にメソッドが呼び出され、手元のコールバックハンドラメソッドが呼び出される、というように通知されます（「Async訪ねて3000里」を参照）。
ここで、TaskCompletionSourceを使い、SetResultやSetExceptionを呼び出すことで、非同期処理の完了を通知します。
従って、非同期処理とは、必ずしも特定のスレッドに紐づいた処理では無い事を意味します。そのため、「実行コンテキスト」という呼び方をしました。更に、呼び出し元のスレッドにとっては、非同期メソッドである事の証は「Taskクラス」だけです。GetStreamAsyncメソッドの戻り値は「Task<Stream>」で、このインスタンスを「await」する事によって待機します。ここでも、スレッド基準ではなくタスク基準です。
タスク基準の非同期処理の管理を行う場合に、タスクを認識して処理を行う主体に名前が欲しいと思う事があるため、特に「タスクコンテキスト」と呼んでいます（公式ではありません）。
さて、ここまでで、「非同期メソッド内の処理の主体」が、必ずしもスレッドに紐づかないという展開をしましたが、これがそっくりそのまま、呼び出し元にも当てはまります。何故なら、呼び出し元は「await」した時点でスレッドによるハードブロックではなく、疑似的に非同期処理を待機しているかのように見せているからです。
スレッドをブロックしない、という事は、この図のように、awaitの直前までのスレッドコンテキストは解放されることを意味します。そのスレッドがどこに行ってしまうのか？はともかくとして、ここでも実行コンテキストはスレッド基準ではなくタスク基準である事が分かります。
GetStreamAsyncがSetExceptionで例外を通知する時、awaitしているタスクコンテキストは起こされ、catchブロックの処理を継続します。処理を継続するにはコードを実行しなければならないため、物理的なスレッドコンテキストが必要です。それは図のように「メインスレッド」なのでしょうか？ 元のメインスレッドはawait時にどこかに行ってしまったかも知れませんね。新たに割り当てられたワーカースレッドが、代わりに処理を継続するかもしれません。処理を継続するスレッドが何になるのかは、「SynchronizationContextクラス」がカギを握っていて、WPFやWindows Formsでは結局メインスレッドが再び処理を継続します。
SynchronizationContextクラスの動作に踏み込むと本題と外れてしまうため、ここでは呼び出し元の処理もまた「非同期メソッド」となり、実行コンテキストはスレッド基準ではなくタスク基準となる、という事が分かれば良いと思います。
タスクベース処理のデバッグ
参考までに、タスク基準でのデバッグ手法について触れておきます。
今まで、スレッドベースでのプログラミングに慣れてきたため、デバッグ時にはどのメソッドがどのメソッドを呼び出して来て今の状態に至るのかを「呼び出し履歴（スタックトレース）」を観察するのが基本でした。しかし、タスクベースの非同期処理をデバッグする場合は、スタックトレースを眺めても何も得られない可能性があります。タスクコンテキストはスレッドに紐づく場合もあればそうでない場合もあり、更にたまたま割り当てられたワーカースレッドによって実行コンテキストが得られている場合もあります。
そのため、Visual Studioのデバッガには「タスク」ウインドウが追加されました。
このウインドウで、待機中のタスクコンテキストの状態と、待機が発生した位置を確認する事が出来ます。残念ながら、その時点の待機に至った履歴（疑似的な、非同期待機のスタックトレースのような）は見る事が出来ません。そのため、各タスク間にどのような依存性があるのかないのかは、このウインドウを見てもはっきりとは分かりません。将来的に改善されると良いなと思います。
例外のスタックトレース（古代CLR）
C# 1.0がリリースされた時、言語仕様がJavaに似ている事から様々な点が比較されました。例外についてもかなり似通っているのですが、決定的に異なる点が少なくとも一つ存在します。それは、スタックトレースの扱いです。C#でやってはいけないと言われている事の一つに、例外の再スローの方法があります。
public static void RethrowExceptionSample()
{
try
{
// 何らかの処理
throw new Exception();
}
catch (Exception ex)
{
// 例外の処理
logger_.WriteLog(ex);
// 再スロー（ここからスタックトレースが再構築されてしまう）
throw ex;
}
}
Javaからの移行組の人はついついやってしまいますが、C#ではこのコードはエラーになりませんがやってはいけません。何故なら、「throw ex」すると、ex内に記録されているスタックトレースの情報が失われ（リセット）、新たにスタックトレースが再構築されるからです。正しい再スローは以下の通りです。
public static void RethrowExceptionSample()
{
try
{
// 何らかの処理
throw new Exception();
}
catch (Exception ex)
{
// 例外の処理
logger_.WriteLog(ex);
// 再スロー（スタックトレースは維持される）
throw;
}
}
throw句に何も指定しなければ、（例外処理ブロック中であれば）その例外が再スローされます。これは、IL命令でのrethrowに変換されます。つまり、特別な処理としてCLRに認識されているのです。
この事は、前述の「Threadクラスで生成したワーカースレッド内で発生した例外を、元のスレッドにどうやって通知するか」と言う事に大きな制約を生じさせます。非同期処理の外側では、内部実装でワーカースレッドを使っているかどうかは関係なく、関心の無い事です。従って、ワーカースレッドを使っていたとしても、メソッド内で発生した例外は、あたかも連続したスレッドコンテキストで発生したかのように、スタックトレースが観察されて欲しい、と思う筈です。
例えば、以下のようなコードで、ワーカースレッドで発生した例外を別のスレッドで再スローしたらどうでしょうか？
public static void RethrowAnotherThreadBoundExceptionSample()
{
// ワーカースレッドで発生した例外を保持する変数
Exception caughtException= null;
// ワーカースレッドの生成
var thread = new Thread(() =>
{
try
{
// 何らかの処理
throw new Exception();
}
catch (Exception ex)
{
// 例外を記録
caughtException = ex;
}
});
// ワーカースレッドの実行と完了の待機
thread.Start();
thread.Join();
// ワーカースレッドで例外が発生していたら
if (caughtException != null)
{
// error CS0156: 引数なしの throw ステートメントは catch 句以外では使えません。
throw;
// スタックトレースを失う
// throw caughtException;
}
}
このコードはコンパイル出来ません。何故なら、再スロー構文「throw」は、catchブロック内でのみ使用出来るからです。かといって、「throw caughtException」と書いてしまうと、スタックトレースを失ってしまいます。
ファッ○ン CLR!!
と思いましたか？ 私は思いましたよ、.NET Remotingを知るまでは。
CLR設計者に聞いたわけではありませんが、この仕様は恐らく意図的なものです。.NETは最初のバージョンから「アプリケーションドメイン」という考え方を導入しています。これは、「マイクロプロセス」と呼べるもので、同一のプロセス内に、サンドボックス的な分離構造を持たせる事が出来る機能です。同一プロセスであっても、異なるアプリケーションドメイン間の通信には大きな制約が生じます。これにより、アプリケーションドメイン間の安全性を高め、かつ、プロセス起動・終了による非常に大きなコストを排除するのが狙いです。
.NET Remotingは、このアプリケーションドメイン間の通信や、プロセスワイド、又はマシンワイド間での「リモート参照」機能を提供して、通信の実装負担を軽減します。リモート参照は一見してクラスやインターフェイスそのものに見えます。そこにはメソッドが定義されていて、メソッドを呼び出すとリモートのメソッドが呼び出されるという、非常に透過的で便利な機構です。
補足：現代においては、CLRのリモート参照機能はややレガシーとして扱われています。一般的にXMLやJSONによるHTTP REST APIが良く使われていますが、そこに皮を被せる形でリモート参照を使うケースはまだまだあるでしょう。また、アプリケーションドメインとは切っても切り離せない関係にあるため、当分の間、CLRリモート参照の機能が廃止されることはないと思われます。
この「リモートメソッドの呼び出し」は、当然、引数や戻り値もハンドリングします。引数や戻り値をリモートメソッド間でやり取りするためには、インスタンスのシリアル化と逆シリアル化という非常に大きなトピックが含まれます。更に、リモートメソッドで発生した例外は、そのまま呼び出し元に例外として通知されます。
例外の通知を実現するためには、例外もまたシリアル化・逆シリアル化可能でなければなりません。シリアル化可能であるためには、例外クラスに含まれる情報が全てシリアル化可能である必要があります。そこには、例外のメッセージ文字列のような単純なものもありますが、「スタックトレース」も含まれているのです。
スタックトレース情報は文字列ではありません（ToStringする事により文字列化されます）。スタックトレースは「StackTraceクラス」や「StackFrameクラス」を使って、実行時に動的にトラバースする事が出来ます。仮に、シリアル化が完全に機能するためには、これらのクラスの中身もシリアル化されなければなりません。StackFrameクラスは、リフレクションのMethodInfoクラスを保持しています。MethodInfoはこれが定義されているTypeクラスを参照し、Typeはそれが定義されたModuleやAssemblyクラスを参照しているでしょう。完全にシリアル化するためには、それらの型情報が保持された全てのDLLが特定されなければならず、逆シリアル化の際には呼び出し元でもすべての参照が解決されなければなりません。
これは明らかに大げさすぎます。リモートメソッド呼び出し側は単に例外の種類（例外クラス）と、メッセージぐらいが判別できれば良いのかもしれません。あるいは例外がスローされることによって、リモート側のスタックの全貌が観察出来てしまうのは、セキュリティリスクです。
このような理由かどうかは分かりませんが、CLRが再スロー可能なタイミングを強制しているのは：
- 「いつでもスタックトレースが維持される」という状況は望ましくない場合がある。
- そうであるなら再スローは限られた状況下でのみ機能するようにデザインすれば良い。
と判断したように見えます。
さて、このようなCLRのデザインの為、残念ながらExceptionクラスは、スタックトレースを維持したまま、別のスレッドで再スローする事が出来ない事になります。.NETのスタンダードなソリューションとして、「TargetInvocationException」というクラスが、元の例外のインスタンスをInnerExceptionに保持してスローする事になっています。こうすれば、元の例外のスタックトレースを失うことなく、新たなスタックトレースを構築できます。但し、元の例外クラスを指定してcatch出来ないため、「何このうっとおしい例外は！」と思うかもしれません。
補足：TargetInvocationException.InnerExceptionに保持したからと言って、スタックトレースの物理的な情報をシリアル化するわけではありません。アプリケーションドメインを超える時、.NET Remotingのインフラが、スタックトレースを文字列のような安全なデータに固定化します。そのため、リモート例外を受信したスレッドは、リモートのスタックトレースの「動的な」トラバースを行う事は出来ません。また、セキュリティ要件として、この機能を構成で無効化する事も出来ます。つまり、例外は捕捉可能でも、スタックトレースは全く参照出来ないようにする事も出来ます（むしろ、プロセス間以上のRemotingは、デフォルトが逆だったかもしれません。忘れてしまいました）。
例外のスタックトレース（CLR 4.0・4.5以降）
昔の話はこれぐらいにしておきましょう。CLR 4.0にてTaskクラスが導入され、タスクベースの非同期処理が可能になりました。しかし、これまで述べてきたスタックトレースの問題は依然として残っています。従って、awaitで待機中のタスクコンテキストに例外を通知する場合でも、迂闊にそのまま通知することは出来ない事になります。
// CLR 4.0以降
public static Task RethrowAnotherThreadBoundExceptionSampleAsync()
{
// タスクコンテキストの拠り所を生成
var tcs = new TaskCompletionSource<object>();
// ワーカースレッドの生成
var thread = new Thread(() =>
{
try
{
// 何らかの処理
throw new Exception();
}
catch (Exception ex)
{
// 例外を通知
tcs.SetException(ex);
}
});
// ワーカースレッドの実行
thread.Start();
// Taskを返す
return tcs.Task;
}
static void Main(string[] args)
{
try
{
// タスクの完了をハードウェイトする
RethrowAnotherThreadBoundExceptionSampleAsync().Wait();
}
catch (Exception ex)
{
Debug.Assert(ex.GetType() == typeof(AggregateException));
Console.WriteLine(ex.ToString());
}
}
もはや忘れているかもしれません（自分でも書いてて思い出した）、async-awaitはCLR 4.5からのサポートです。従って、上記のようなコードを書いても、await時にどうなるかは分かり難いですね。Task.Waitメソッドを呼び出してハードウェイトした場合、発生した例外は「AggregateExceptionクラス」という、新たなクラスに保持されてスローされます。使われ方はTargetInvocationExceptionと同じですが、AggregateExceptionは複数の例外を内包出来るところが異なります。つまるところ、それまでのスタックトレースは維持されるものの、結局スタックトレースは結合されず分断される、と言う訳です。
スクリーンショットは、処理中に「throw new Exception()」を発行した様子です。先頭はcatchしたAggregateExceptionで、下の方に辿っていくと「（内部例外 #0）」という行が見つかります。この行が、AggregateExceptionが内包しているExceptionクラスの例外のスタックトレースです。シームレスに繋がっているように見えるのは、ToStringがうまく文字列フォーマットしているだけで、本質的にスタックトレースが結合している訳ではありません。
これが、CLR 4.5以上でasync-awaitを使い、非同期的に待機した結果、どうなるかと言うと：
// 非同期待機（await）出来るようにするため、非同期メソッドを定義
public static async Task CallerAsync()
{
try
{
// 非同期メソッドを呼び出して非同期的に待機
await RethrowAnotherThreadBoundExceptionSampleAsync();
}
catch (Exception ex)
{
Debug.Assert(ex.GetType() == typeof(Exception));
Console.WriteLine(ex.ToString());
}
}
static void Main(string[] args)
{
CallerAsync().Wait();
}
スクリーンショットを見て分かりますか？ AggregateExceptionがありません。catch句はまるでExceptionクラスの例外を直接受信しているかのようです。実際に、catch句のexは、Exceptionクラスのインスタンスです。これでは、まるでスタックトレースがシームレスに結合しているようではありませんか！！
重要な事です：awaitで非同期待機中に受信した例外は、スタックトレースが結合され、同期メソッドの例外と同じように振る舞います。
今までは不可能な事だったので、これには仕掛けがあります。CLR 4.5で新たに追加された「ExceptionDispatcherInfoクラス」を使います。一般の開発者がこのクラスを直接操作するのは、あまり良い事ではありません。フレームワーク設計者はこのクラスを使って、スタックトレースを厳密に操作したくなるかもしれませんね。
もし、await待機中に受信した例外が全てAggregateExceptionにラップされてしまうと、async-awaitを使用したプログラミングはかなり非効率的になってしまいます。すべての例外はAggregateExceptionをキャッチし、改めて内包例外を判定する必要があります。これでは、細部を知らない開発者は「なんでこんな変な事になっているんだ」と文句を垂れる事になるでしょう。
しかし、スタックトレースが結合され、AggregateExceptionを使わない事で、今まで掘り下げてきたことは何も知らなくても、とりあえずasync-await構文を使って普通にコードが書ける、という、最初の説明に繋がるわけです。
CLRの世代を経て、結局スタックトレースが維持可能になったのは少し残念ですね。これではTargetInvocationExceptionやAggregateExceptionは何だったのかと思えてきます。しかも、いまさら無理な話ですが、Task.Waitの挙動もExceptionDispatcherInfoを使えばスタックトレースを結合出来てウハウハではありませんか (;´Д｀)
しかし、再度この問題をひっくり返すネタが、次の本題です。
放置された非同期処理の行方
さて、ようやく本題です。この記事を書こうと思った要因となるネタですが、今までの説明はこの話の導入に必要でした。以下のように、2つのI/O操作を効率よく実行するため、それぞれを非同期メソッド呼び出しで開始させ、その後awaitで完了を待ちます。
public async Task ExecuteMultipleIOAsync(Stream stream1, byte[] data1, Stream stream2, byte[] data2)
{
try
{
// 非同期処理を開始
var task1 = stream1.WriteAsync(data1, 0, data1.Length);
var task2 = stream2.WriteAsync(data2, 0, data2.Length);
// それぞれの完了を待機
await task1;
await task2;
}
catch (Exception ex)
{
Console.WriteLine(ex.ToString());
}
}
このような実装はデザイン的に避ける必要があります。とりあえず、一例を図示してみましょう。
メソッド内部で呼び出した非同期メソッドは、それぞれtask1, task2のバーで示しました。これらの非同期メソッドの内部で何が行われているのかは不明です。ワーカースレッドを使っているのかもしれませんし、ネイティブなWin32 APIによって駆動されているのかもしれません。単にそれらを緑枠で「タスクコンテキスト」として扱っています。
二つのサブタスクはほぼ同時に開始されます。メインタスクとは関係なく非同期で動作するため、サブタスクのどちらが先に終了するのかは、良く分かりません。図中では、task1→task2の順で完了した場合を示しています。
仮に逆だった場合：
メインタスクは「await task1」として、task1の完了を先に待機しているため、通知もtask1→task2の順になります。つまり、非同期処理の順序がどのように処理されたとしても、両方の完了が正しく処理されるのです。
…
本当でしょうか？
この例は、task1は処理が成功し、task2は失敗して例外をスローするパターンです。「await task1」は完了し、「await task2」にて例外が再スローされ、catchブロックでキャッチされます。何も問題なさそうですね？
逆のパターンはどうでしょうか：
task1の処理が失敗して例外がスローされた場合、メインタスクは例外を受け取ってcatchブロックで処理します。すると、非同期で動作中のtask2の結果（正常終了）を受け取る機会が失われます。何故ならもう「await task2」という文は実行されないからです。
正常終了の通知を受け取らなかった場合、その通知はどうなってしまうのか？
とても重要：どうにもなりません
この通知は、メインタスクだけでなく、あらゆるタスクが受け取る機会を失います。従って、この結果通知は「無視」されます。このコード例では、WriteAsyncは結果を返しません（非ジェネリックなTaskを返します）。そのため、task2が成功しようが失敗しようが、結果を確認できなかったとしても、恐らく問題にはなりません。メインタスクの「関心」は、task1が例外をスローした時点で例外処理に遷移しているのです。task2がどうなろうが、知ったことではない… と解釈されます。
さあ、問題の核心です：
もう、何となくわかったかもしれません。この図では、task1もtask2も処理に失敗して例外を通知しようとします。task1はawaitしているので、その時点で例外が通知され、メインタスクはcatch句に遷移し、例外が処理されます。task2の例外は通知しようにも、受け取るタスクが無いのです。前の例と同じように、「await task2」は実行されないので、
きわめて重要：task2の例外（あるいは成功）は、メインタスクで処理「されません」
最初に解説した通り、async-awaitの構文は、殆ど同期メソッドを使用したコードと同じように、非同期メソッドの実装を可能にします。しかし、本質的には全く動作が異なるのです。この問題は、同期メソッドの実装の感覚で理解していると、ハマってかつ理解不能、というパターンかも知れません。
task1とtask2を順番にawaitするというコードは、意図して書いたのであれば問題ありません。意図してという事は、「task2がどうなろうと知ったことではないが、task1が正常に終了するときには面倒を見たい」のような場合です。こういう要求は、現実には殆ど無いと言って良いと思います。従って、このようなコードを書かないように注意する必要があります。
この問題に対処する方法ですが、まず、成功はともかく、例外が完全に無視されてしまうのは問題と思われます。「無視されず、例外が発生すればいいんでね？」と思うかもしれません。その通りではあるのですが、受け取るタスクが存在しないのです。実は例外を発生させる方法はあります。それは、App.configに次のような指定を入れる事です。
<configuration>
<runtime>
<ThrowUnobservedTaskExceptions enabled="true"/>
</runtime>
</configuration>
この指定は、CLR 4.5移行で有効です。CLR 4ではこの指定に関わらず、「UnobservedTaskException例外」がスローされます（CLR 4ではasync-awaitが使えないので、これはあまり問題にならないかもしれません）。しかし、例外をスローしても、受け取るタスクが居ないんでしたよね。誰がどこからスローするんだ？という話になるのですが、実は「TaskExceptionHolder」という内部クラスが、「ファイナライザースレッドコンテキスト」でスローします。
ファイナライザースレッドなので、これが分かったとしても何も出来ません。何かしても、もう手遅れで、この後プロセスは死亡します。そもそもこの例外を受け取れる可能性があるのは、「AppDomain.UnhandledExceptionイベント」しか無い、という事になります。
そのようなわけで、もう少し使いやすいイベントハンドラがあります。「TaskScheduler.UnobservedTaskExceptionイベント」です。このイベントをフックすれば、発生した非同期例外と、その例外を「処理済み」としてマークするかどうかの選択肢が得られます。例えば、ログに記録してから無視する、等の方法が取れます。
起きてしまった非同期例外のフォローはこのような対策ですが、そもそも問題を起こさないようにするには、どうすれば良いでしょうか？
public async Task ExecuteMultipleIOAsync(Stream stream1, byte[] data1, Stream stream2, byte[] data2)
{
// 非同期処理を開始
var task1 = stream1.WriteAsync(data1, 0, data1.Length);
var task2 = stream2.WriteAsync(data2, 0, data2.Length);
try
{
// task1の完了を待機
await task1;
}
catch (Exception ex)
{
Console.WriteLine(ex.ToString());
}
try
{
// task2の完了を待機
await task2;
}
catch (Exception ex)
{
Console.WriteLine(ex.ToString());
}
}
しかし、これは面倒です。awaitの度に、例外が発生したか否かをいちいちcatchで確認しなければなりません。根本的には、Taskインスタンスを持ってまわるようなコードを書いた時点で、不測の事態が起きうることを覚悟する必要があります。どうしてもこのようなコードを書かなければならないのか、は考える必要があります。
もっと良い例を挙げましょう：
public async Task ExecuteMultipleIOAsync(Stream stream1, byte[] data1, Stream stream2, byte[] data2)
{
// 非同期処理を開始
var task1 = stream1.WriteAsync(data1, 0, data1.Length);
var task2 = stream2.WriteAsync(data2, 0, data2.Length);
try
{
// task1とtask2のの完了を同時に待機
await Task.WhenAll(task1, task2);
}
catch (Exception ex)
{
// （非同期例外であれば、AggregateExceptionに内包されている）
Console.WriteLine(ex.ToString());
}
}
原点回帰、というか、Task.WhenAllを使って複数のタスクを同時に待機します。今回の例はtask1とtask2が完了するのを待つ、というのが主目的なので、WhenAllを使えば目的は達成します。しかも、片方又は両方で例外が（どのような順序で）発生した場合でも、確実に例外を補足できます。
そして、ここで、AggregateExceptionの必要性が生まれます。前節でスタックトレースの結合が出来た事で、AggregateExceptionのような例外内包クラスは不要ではないかという例を示しましたが、非同期で発生する複数の例外を安全に呼び出し元のタスクに通知するために、この例外が必要になるのです。
長くなりましたが、非同期例外にまつわる技術的な背景を書いてみました。より安全な非同期処理が書けると良いですね。
今年も年末に突入しました。この記事は「Windows Phone / Windows 10 Mobile Advent Calendar 2015」の4日目の記事の前編です。（前日に公開しています。本編は予定通り明日公開です）
