質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

新規登録して質問してみよう
ただいま回答率
85.50%
C#

C#はマルチパラダイムプログラミング言語の1つで、命令形・宣言型・関数型・ジェネリック型・コンポーネント指向・オブジェクティブ指向のプログラミング開発すべてに対応しています。

.NET Framework

.NET Framework は、Microsoft Windowsのオペレーティングシステムのために開発されたソフトウェア開発環境/実行環境です。多くのプログラミング言語をサポートしています。

Q&A

4回答

4132閲覧

.NET 4.5での例外仕様変更の理由は何でしょうか?

hazurin

総合スコア6

C#

C#はマルチパラダイムプログラミング言語の1つで、命令形・宣言型・関数型・ジェネリック型・コンポーネント指向・オブジェクティブ指向のプログラミング開発すべてに対応しています。

.NET Framework

.NET Framework は、Microsoft Windowsのオペレーティングシステムのために開発されたソフトウェア開発環境/実行環境です。多くのプログラミング言語をサポートしています。

1グッド

2クリップ

投稿2018/03/23 03:25

http://www.atmarkit.co.jp/ait/articles/1512/16/news026.html
↑の解説によれば、

 バックグラウンドタスクの完了を待機しない場合には、次のように仕様が変わっている。
.NET 4.0: トラップされなかった場合は、プログラムが終了する
.NET 4.5: トラップされなかった場合は、その例外は失われる(既定値)
この.NET 4.5の動作は、.NET 4.0と同じ動作をするように変更できる。本稿では、.NET 4.0と同じ動作に変更しておく。
それには環境変数やレジストリを設定する方法もあるが、ここでは動作環境によらずアプリごとに設定する方法を用いる。
.NET 4.5のプロジェクトの場合は、App.configファイルでThrowUnobservedTaskExceptionsをtrueに設定しておいてもらいたい(次のコード)。

とあります。実際、この解説には間違いがなく、言われたとおりに設定すれば、4.0の動きに戻りました。

なので、動きそのものについては、そうなっていることが確かめられたのですが、なぜ仕様変更されたのかの理由が分かりません。
仕様変更の理由についてご存知の方がいらっしゃれば教えてください。


特に、

<runtime> <ThrowUnobservedTaskExceptions enabled="true"/> </runtime>

と設定してはいけない、または、推奨されない理由があれば、そのような理由を教えていただければと思います。

また、
https://docs.microsoft.com/ja-jp/dotnet/framework/configure-apps/file-schema/runtime/throwunobservedtaskexceptions-element
↑の解説を読むと

タスクに基づく非同期コードを記述する開発者向け容易にできるように、
.NET Framework 4.5観察されない例外のこの既定の動作を変更します。
無視された例外が、UnobservedTaskExceptionイベントが発生する、
既定では、プロセスを終了しません。
代わりに、イベント ハンドラーが例外を監視するかどうかに関係なく、
イベントが発生した後に、例外が無視されます。

とあります。しかし、想定していない例外が発生した場合、プロセスを停止しない理由が分かりません。
開発しているアプリケーションはクライアントアプリであり、サーバーなどではないため、常時起動が求められているわけでもありません。
想定外の例外が発生した場合は、ログ出力とエラーメッセージ表示を行いプロセスを終了して、ログとエラーメッセージから、
原因を追及すべきと考えています。
私の考えは間違っているのでしょうか?

なぜ、例外の仕様が変更されたのか教えてください。
そして、繰り返しになりますが、上の設定が非推奨または禁止であれば、それを教えて下さい。

umyu👍を押しています

気になる質問をクリップする

クリップした質問は、後からいつでもMYページで確認できます。

またクリップした質問に回答があった際、通知やメールを受け取ることができます。

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

guest

回答4

0

こんにちは。

4.0の仕様だと実にヤバイ例が以下で読めます(下の方です)。
neue cc - asyncの落とし穴Part2, SynchronizationContextの向こう側

質問者さんはクライアントアプリケーションだそうですが、4.0の仕様だと非同期例外はプロダクション環境のWebサーバアプリケーションであっても問答無用で落とします(ヤバイ)。

まあ、非同期だろうがなんだろうが、例外のcatch忘れというプログラムの欠陥であることは間違いないのですが、当時Taskが登場したばかりで非同期処理もこなれていない時期の話題であり、非同期メソッドでの例外処理は同期とは扱いが変わってくる部分もあるので、アプリケーションの健全性より持続性に寄せたということなのでしょうね。

開発しているアプリがクライアントアプリケーションであり、async/awaitによるフロー構築に慣れていて、例外処理を確実に行えてると言えるのであれば、ThrowUnobservedTaskExceptionsをtrueにしておいたらバグが表面化するので、設定してみても良いんじゃないでしょうか。


上の記事の中にあったリンクですが、まさに「なぜ仕様が変更されたのか」について言及している公式記事なので張っておきます。
Task Exception Handling in .NET 4.5 | Parallel Programming with .NET

投稿2018/03/23 05:37

編集2018/03/23 05:54
tamoto

総合スコア4103

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

tamoto

2018/03/23 05:51

長かったのであとにしてたんですが、ようやく読み終わったので回答に追記しますー
guest

0

なぜ仕様変更したのか、実際のところはマイクロソフトに聞かないと判らないでしょうけど、結局4.0仕様では何かの不都合があったのでしょうね。

簡単な実験をしてみました。

C#

1private void button1_Click(object sender, EventArgs e) 2{ 3 var task = Task.Run(() => 4 { 5 throw new ApplicationException("スレッド内で例外"); 6 }); 7 //task.Wait(); 8} 9 10private void button2_Click(object sender, EventArgs e) 11{ 12 GC.Collect(); 13}

最初はbutton1のみでしたが、これだとApp.configに<ThrowUnobservedTaskExceptions enabled="true"/> と書いたのに無反応でした。ちょっと調べたら、4.0仕様でのスレッド内でハンドルされない例外は、GCで回収されるときにプロセスを終了させるとのことなので、その確認のためbutton2を追加しました。実際その通りでした(「<ThrowUnobservedTaskExceptions>要素」の説明ページのサンプルコードでGCが出てくる理由を理解)。

想定外の例外が発生した場合は、ログ出力とエラーメッセージ表示を行いプロセスを終了して、ログとエラーメッセージから、
原因を追及すべきと考えています。

実験結果から、4.0仕様ではスレッド内で処理されない例外がプロセスを終了させるタイミングは**予測不可能(GCのタイミング次第)**ということになり、それはちょっとあんまりではないかという気がします。
忙しく働くプログラムならすぐにGCが発動するでしょうけど、そうでないならいつまでたってもエラーが検知されないことになります。

要するに、不安定要素を抱えたアサーションによるエラー検知になど期待せずに、ちゃんと自分でエラーのハンドリングをしなさい、ということでしょう。

投稿2018/03/23 05:47

catsforepaw

総合スコア5938

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

0

おもしろそうな話題で気になったので少しぐぐってみました。
結論としては仕様変更の理由は明確には明言されていませんでした。

ただ2点ほど見つかった内容があるので、情報共有のためコメントを投稿致します。

1,「Rationale Exception UnobservedTaskException」でキーワード検索すると以下のmicrosoft開発ブログがヒットしました。

FAQ :: TaskScheduler.UnobservedTaskExceptionイベントが機能しませんか?

■ぐーぐる翻訳

タスク本体からスローされた例外が観測されないまま放置されると、それらはエスカレートされることを思い出してください。.NET 4では、Taskオブジェクトがガベージコレクションに使用できるようになった後、TPLがファイナライザにそれらをスローすることを意味します。TaskSchedulerクラスのUnobservedTaskExceptionイベントは、このような例外を監視してプロセスをクラッシュさせないための最後の手段として追加されました。

2,.NETコアのコーディングガイドライン breaking-change-rules.md
DOTNET / corefx / Documentation /coding-guidelines/ breaking-change-rules.md

■ぐーぐる翻訳

APIがより堅牢な動作を可能にしたり、新しいシナリオを有効にしたりしたときにスローされていた例外を削除する

投稿2018/03/23 05:39

umyu

総合スコア5846

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

0

同じ動作にできるのですからしていけないことはありません。
その方がいいならそうしてください。

プログラムが停止しないことの利点はログを取っていなくてもその時点の変数やオブジェクトの状態を確認してデバッグできることです。
細かくログを取っていてデバッグに支障がないなら別に構いません。

しかしログを取れそうすべきだと声高に叫ぶ前にまず想定していない例外が発生しないようきちんとキャッチしましょう。
そして仕様変更の公式な意見が聞きたいならここではなくマイクロソフトに尋ねてください。

投稿2018/03/23 04:07

Zuishin

総合スコア28656

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

あなたの回答

tips

太字

斜体

打ち消し線

見出し

引用テキストの挿入

コードの挿入

リンクの挿入

リストの挿入

番号リストの挿入

表の挿入

水平線の挿入

プレビュー

まだベストアンサーが選ばれていません

会員登録して回答してみよう

アカウントをお持ちの方は

15分調べてもわからないことは
teratailで質問しよう!

ただいまの回答率
85.50%

質問をまとめることで
思考を整理して素早く解決

テンプレート機能で
簡単に質問をまとめる

質問する

関連した質問