最近、仲間の開発者と興味深い会話をしました。彼は、「try」を書くたびに「catch」を提供することが必須であると教えてくれました。彼は、なぜこの規則を採用したのか説明できませんでした。彼は、それが優れたプログラミングの原則であると私に言いました。なぜこのルール？
参考までに、私は彼に同意しません。「finally」ブロックだけで「try」ブロックを書くこともあると思います。しかし、「キャッチ」を書く場合、キャッチで何かをしなければならないと私が思うのは事実です。エラーを再スローしないでください。
catchその通りです。例外をどう処理すればよいかわからず、finally句が確実に実行されるようにするだけであれば、句を記述する必要はありません。
catch例外を再スローするためだけに句を追加するのは悪い習慣です。
余談ですが、 と が実際には 2 つの異なる (明らかに異質ではない) 問題に関連していることを説明するcatchためfinallyに、一部の言語では例外のキャッチに異なる構造を使用し、一部のコード (通常はリソースの解放) が実行されるようにすることに注意してください。deferたとえば、使用してください。
ほとんどのアプリケーションでは、コンストラクトの数がコンストラクトのtry/finally数を大幅に上回りtry/catchます。
処理方法を知っている例外を受け取るよりも、リソースをクリーンアップする方がはるかに一般的だからです。
ただしtry/finally、ほとんどの場合、C# では に置き換えることusingができるため、C# では、開発者はその場合にポイントを持っている可能性があります。しかし、それは間違いなく「優れたプログラミングの原則」ではありません。
try
{
...
}
finally
{
...
}
try ブロックで例外がスローされた場合に見逃してしまうコードを、finally ブロックで実行する機会を提供します。例外が発生したときに特定の処理を行う必要がある場合にのみ、catch ブロックを追加する必要があります。