c# - finally ブロックで例外をスローすることは良い習慣ですか?

Question

良い質問がありますCatch ブロックが評価されていないときに例外がスローされたときに、finally ブロックで例外をスローした場合の予期しない結果について説明しています。

finally ブロックで例外をスローする正当な理由は思いつきません。以前の例外があった場合、それは常に失われます。私はいつも、例外をスローしてはならない方法で最終的にクリーンアップするのを見てきました。

finally ブロックで例外をスローするのが適切な場合を誰か説明できますか?

Answer 1

try catch finally は非常に重要な構造です。例外がスローされても、finally ブロック内のコードが実行されることを確認できます。それらを解放するために外部リソースを処理することは非常に重要です。ガベージ コレクションはそれを行いません。最後に、return ステートメントを使用したり、例外をスローしたりしないでください。それを行うことは可能ですが、それは悪い習慣であり、予測できない結果につながる可能性があります。

Answer 2

最終的にExceptionスローされると、それは伝播し、最も重要なポイントで最終的に停止するExceptionため、最終的に残りの部分は実行されません。また、try ブロックで例外が発生した場合、それは消滅し、現在の例外が finally ブロックからスローされます。

Exception最終的にスローしてから、特定の理由で呼び出し元レベルでそれを処理するシナリオを考えることができません(そのようなロジックを管理する他の方法がある可能性があります)。Exception投げられたものに基づいてさらにレベルプロセス。

私が言えることは、後でコードを読んで従おうとするすべての目は、健全な驚きを持っているということです.

Answer 3

それは問題なく、.NET によって十分にサポートされています。問題は例外をキャッチすることです。これは非常に貧弱な方法です。プログラムの状態を適切に復元できる可能性は非常に低いです。