Try-Catch内ですべてのステートメントを記述する必要があるのはなぜですか？

私の会社長は、すべてのコード、つまりTry-catchステートメント内のすべてのコードを記述する必要があると言います。ここで、「申し訳ありませんが安全です」というアプローチはここで理解できますが、ラベルが作成され、フォームの位置が設定されたときに例外があると考えるのはあまりにも簡単ではありません。このような単純な操作で例外が発生する場合があります。

私の会社長は、すべて、つまりTry-catchステートメント内のすべてのコードを記述する必要があると言います。

まあ、これは少しやり過ぎで、ノイズの多いコードになります。try catchハンドラーですべてのコード（各メソッドなど）を作成することの利点は何ですか？ほとんどの場合、修正すべきエラーがあることを伝えるだけです。多くの場合、そもそも例外は回避できますし、回避すべきです。

フォールトメソッドがcatch自体を実行しない場合でも、スタックトレースを調べるだけでコードの原因を明らかにできます。開発者が例外でスタックトレースを破損する場合がありますが、多くの例外ハンドラを使用している場合ははるかに多くの場合です。何でもそうです：少しでも良いですが、あまりにも多くは毒です。

例外処理は確かに非常に簡単です。

例外をキャッチ

• 例外への反応として特別なアクションが必要なときはいつでも
• 例外が処理されない場合、プログラムが一貫性のない状態のままになるたびに

考えてみると、ほとんどの場合、発生する例外を処理するのに適した場所は1つだけです。したがって、ハンドラーはその場所にある必要があります。

多くの例外はそもそもスローされるべきではないので、例外処理を中心に制御構造を構築せず、いつでもどこでも可能な例外の発生を避けるようにしてください。

物事が（修復不可能に）間違った場合は、早期にクラッシュすることを忘れないでください。すべてのコードをtry-catchステートメントに入れるのは馬鹿げていますが、すべての例外を報告して記録することを忘れないでください。

しかし、ラベルが作成され、フォームの位置が設定されたときに例外があると考えるのはあまりにも簡単ではありません。このような単純な操作で例外が発生する場合があります。

はいぜったいに！あなたが予見しなかった事がうまくいかない方法が常にあります。また、「チキンハート」は、このコンテキストで使用するばかげた表現です。ソフトウェア開発は、潜在的な問題を無視してmachismoを証明することではありません。

有効な質問とは、コーディング標準で必要とされている時点で例外をキャッチすることが有用かどうかです。あなたのステートメントは、すべてのメソッド本体の周りにtry / catchブロックを持たなければならないように見えますが、例外で有用なことをすぐに行うことができないことが多いため、それは本当にばかげています。適切な時点で処理されるコールスタックを伝播します。

私はこれを逆に回します。はい、一般的なルールとして、例外処理は良いことですが、実際には、キャッチされた時点で考えられるすべての例外を賢明な方法で処理できますか？時々、特にミッションクリティカルなソフトウェアを書いていない場合は、物事が恐ろしく悪くなったときに、途中で制御された方法で単にクラッシュして焼いた方が良いでしょう。

キャッチされる可能性のあるすべての例外を処理できることを100％確信できない場合は、何らかの一般的な例外ハンドラーを作成して、プログラムのメインループをラップすることをお勧めします。あなたが作業しているどのような言語に依存あり、することができますように例外に関する多くの詳細としてログオンし、プログラム状態（どこかに保存します。他のデータは、ユーザーが現在不利に働いている保存何よりも-覚えて、それがすべてのこの時点では壊れている可能性があります）、 等々。次に、例外を再スローし、OSに適切に処理します。このキャッチオール例外ハンドラでは、壊滅的な障害に備えてください。次に、プログラムを再起動したときに、この状態が何らかの意味で有用かどうかを確認し、有効であれば復旧できるものを復元します。バグ報告をあなたに送り返すようにユーザーに提案することもできます。

catchブロックはリソースの点から見て非常に高価なので、全体的にtry / catchの使用は推奨されません。Try / catchの使用は、リスク管理を思い出させます。リスク管理には2つの側面があります。

1. リスク発生の確率
2. 受けるダメージ

さて、家を出ると、どこかで頭にピアノが落ちますが、起こりそうにないかもしれませんが（0.001％）、あなたを殺すことができます。

例外処理はそのようなものです。試行ブロックは高価ではありません。しかし、キャッチブロックは、スタックトレースのテーブルを作成する必要があるため、非常に高価です。したがって、try / catchブロックに関する決定を行う際には、catchブロックにヒットする可能性がある回数を考慮する必要があります。10,000回の使用のうち、1回だけヒットしてから使用します。しかし、それがフォームであり、ユーザーがおそらく50％回正しく入力しない場合は、そこでtry / catchブロックを実行しないでください。

例外が発生する可能性が高い場所では、例外の発生if {} else {}を避けるためにブロックを使用することをお勧めします。たとえば、次のように書く代わりに、2つの数値を除算する場合：

try
{
    int result = a/b;
}
catch (DivisionByZeroException ex)
{
    // Showing a message here, and logging of course.
}

あなたは書くべきです：

if (b == 0)
{
    int result = a/b;
}
else
{
    // Showing a message to user to change the value of b, etc.
}

必要に応じてtry-catchを使用する必要がありますが、すべての例外をキャッチせず、ログも記録しないでください。その時点では、コードのにおいと見苦しい作業です。

私は個人的に例外に耐えることができません、それらは非常に、非常に、非常に正しく処理するのが非常に難しいです。そして、破損したデータを破損させないようにすることは、非常に困難です。

http://blogs.msdn.com/b/mgrier/archive/2004/02/18/75324.aspx

http://blogs.msdn.com/b/oldnewthing/archive/2004/04/22/118161.aspx

http://blogs.msdn.com/b/oldnewthing/archive/2005/01/14/352949.aspx

http://www.joelonsoftware.com/items/2003/10/13.html

次のようなすべての関数を呼び出さない場合：

try
{
    TrivialFunction();
}
catch(TypeAException)
{
    //MaybeFix
}
catch(TypeBException)
{
    //MaybeFix
}
catch(TypeCException)
{
    //NO FIX - CORRUPT DATA
}
catch(TypeDException)
{
    //NO FIX - UNKNOWN STATE
}
catch(OutOfMemoryException)
{
    //Try to fix this one! Destructors might allocate on their own ;)
}
catch(Exception)
{
    //Nothing to see here, move on, everything is OK ;)
}

すべての出口点で正しくクリーンアップする方法はありません。例外は厳しいです！

例外の唯一の良い点は、それらをキャッチしないと、予期しない動作でアプリがクラッシュすることです。