MVCで試してみましょうか。WebForms?しらね。View();}死にました!警告一切ないのに!って、ああ、そうですね、async=”true”にしないとですね、まぁそれはないのですけれど、はい、Task<ActionResult>を返しましょう。View();}はい、死にました!非同期操作が保留中に非同期のモジュールとハンドラーが完了しちゃいましたか、しょーがないですね。voidがあると詰みます。View();}死にます。上で5秒待機を1秒待機に変えれば、動きます。いうと、KusoClass.Sinuを実行のあとに2秒待機があってViewを返してるので、Viewを返すまでの間にKusoClass.Sinuの実行が完了するから。View返すまでに完了してればセーフ。ようするに、死ぬってことですね結局やっぱり。死ぬ、とかいう状況に陥ると、むしろ検出しづらくて厄介極まりないので、死ぬなら潔く死ねって感じ。検出されずそのまま本番環境に投下されてしまったら......!あ、やった人がいるとかいないとかいるらしい気がしますが気のせい。voidが眠ってたら死ぬとか、どーせいという話です。void使っちゃダメ。あるだけで死んでしまうのですから。View();}あー、警告ウザす警告ウザす。その場合、しょうがなく変数で受けたりします。View();}はたしてそれでいーのか。それに、やっぱこれだと例外発生した時に捉えられないですしね。TaskScheduler.UnobservedTaskExceptionに登録しておけば大丈夫ですけれど(&これは登録必須ですが!)。いうわけで、以下の様なものを用意しましょう。投げっぱなしにする場合は、これを呼ぶことでコンパイラの警告の抑制と、例外発生時のロギングを行います。View();}いいんじゃないでしょうか?ところで、ToaruAsyncMethodに.ConfigureAwait(false)をつけてるのは理由があって、これつけないと死にます。SynchronizationContextの向こう側に書きましたが、リクエストが終了してHttpContextが消滅した状態でawaitが完了するとNullReferenceExceptionが発生するためです。これで発生するNullReferenceExceptionは、FireAndForget拡張メソッドを「通りません」。なると、例外が発生したことはUnobservedTaskExceptionでしか観測できないし、しかも、そうなるとスタックトレースも死んでいるため、どこで発生したのか全く分かりません。FireAndForgetで警告が抑制できたとしても、非同期の投げっぱなしは細心の注意を払って、呼び出しているメソッド階層の奥底まで大丈夫であるという状態が確認できていて、ようやく使うことができるのです。それを考えると、ちゃんと警告してくれるのはありがたいね、って思うのでした。まとめvoidはまぢで死ぬ。投げっぱなしも基本死ぬ。我々は非同期を多用するのか。それはハイパフォーマンスの実現には欠かせないからです。それだけじゃなく、asyncでしか実現できないイディオムも山のようにあるので。void使わないとか当たり前なのでそこ守れば大丈夫なんですよ(棒)。voidなんてあるんだよとか言われると、イベント機構があるからしょうがないじゃん(ボソボソ)、とか悲しい顔にならざるを得ない。いうわけで、弊社は非同期でゴリゴリ地雷踏みたいエンジニアを大募集してます。