一般的な例外をキャッチするのは本当に悪いことですか？

私は通常、ほとんどのコード分析の警告に同意し、それらを順守しようとします。しかし、私はこれで苦労しています：

CA1031：一般的な例外タイプをキャッチしない

このルールの根拠を理解しています。しかし、実際には、スローされた例外に関係なく同じアクションを実行したい場合、それぞれを具体的に処理するのはなぜですか？さらに、特定の例外を処理する場合、呼び出しているコードが変更されて将来新しい例外がスローされるとどうなりますか？次に、その新しい例外を処理するためにコードを変更する必要があります。一方、単にExceptionコードをキャッチしただけなら、変更する必要はありません。

たとえば、FooがBarを呼び出し、FooがBarによってスローされた例外のタイプに関係なく処理を停止する必要がある場合、キャッチしている例外のタイプを特定することに利点はありますか？

たぶんより良い例：

public void Foo()
{
    // Some logic here.
    LogUtility.Log("some message");
}

public static void Log()
{
    try
    {
        // Actual logging here.
    }
    catch (Exception ex)
    {
        // Eat it. Logging failures shouldn't stop us from processing.
    }
}

ここで一般的な例外をキャッチしない場合は、可能なあらゆる種類の例外をキャッチする必要があります。パトリックには、OutOfMemoryExceptionこの方法で対処すべきでない良い点があります。では、例外をすべて無視したい場合はどうしOutOfMemoryExceptionますか？

これらのルールは一般的に良いアイデアであり、従って従う必要があります。

しかし、これらは一般的なルールであることを忘れないでください。すべての状況をカバーしているわけではありません。それらは最も一般的な状況をカバーしています。特定の状況があり、テクニックが優れているという議論ができる場合（そして、そうするための議論を明確にするためにコードにコメントを書くことができるはずです）、そうする（そして、ピアレビューを取得する）ことができます。

引数の反対側。

上記の例は、そうするのに適した状況ではないと思います。ロギングシステムに障害が発生している場合（おそらく他の例外をロギングしている場合）、おそらくアプリケーションを続行したくないでしょう。終了し、例外を出力に出力して、ユーザーに何が起こったかを確認できるようにします。

はい、一般的な例外をキャッチするのは悪いことです。通常、例外とは、プログラムがユーザーが要求したことを実行できないことを意味します。

処理できる例外にはいくつかの種類があります。

• 致命的な例外：メモリ不足、スタックオーバーフローなど。一部の超自然的な力があなたの宇宙を台無しにし、プロセスはすでに死にかけています。状況を改善することはできませんので、あきらめてください
• 使用しているコードにバグがあるため、例外がスローされました。それらを処理しようとせずに、問題の原因を修正してください。フロー制御に例外を使用しないでください
• 例外的な状況：これらの場合にのみ例外を処理します。ここに含めることができるのは、ネットワークケーブルが接続されていない、インターネット接続が機能しなくなっている、権限が欠落しているなどです。

ああ、そして一般的なルールとして：もしあなたがそれを捕まえて例外をどうするかわからないなら、ただ速く失敗するほうが良いです（呼び出し元に例外を渡し、それを処理させます）

一番外側のループには、これらのいずれかを表示して、可能な限りすべてを印刷し、恐ろしく暴力的で騒々しい死を遂げます（これは起こるべきではなく、誰かが聞く必要があるためです）。

それ以外の場合は、この場所で発生する可能性のあるすべてのことを予想していない可能性が高いため、通常は非常に注意する必要があります。できるだけ具体的に考えて、発生することがわかっている人だけをキャッチし、前に見られなかった人だけが上記の騒々しい死までバブルするようにします。

それは悪いことではなく、特定の漁獲量が優れているということです。 具体的に言うと、アプリケーションが何をしているかをより具体的に理解し、それをより細かく制御できることを意味します。 一般に、例外をキャッチし、ログに記録して続行するという状況に遭遇した場合、とにかくいくつかの悪いことが起こっている可能性があります。 コードブロックまたはメソッドがスローする可能性があることがわかっている例外を具体的にキャッチしている場合、ログを記録して最善を期待するのではなく、実際に回復できる可能性が高くなります。

2つの可能性は相互に排他的ではありません。

理想的な状況では、メソッドが生成する可能性のあるすべての種類の例外をキャッチし、例外ごとに処理し、最後に一般的なcatch句を追加して、将来または未知の例外をキャッチします。これにより、両方の長所を最大限に活用できます。

try
{
    this.Foo();
}
catch (BarException ex)
{
    Console.WriteLine("Foo has barred!");
}
catch (BazException ex)
{
    Console.WriteLine("Foo has bazzed!");
}
catch (Exception ex)
{
    Console.WriteLine("Unknown exception on Foo!");
    throw;
}

より具体的な例外をキャッチするには、それらを最初に配置する必要があることに注意してください。

編集：コメントに記載されている理由により、最後のキャッチに再スローを追加しました。

私は最近同じことを熟考しており、私の暫定的な結論は、.NET Exception階層がひどく台無しになっているため、単なる質問が生じるということです。

たとえば、キャッチしたくない例外の妥当な候補でArgumentNullExceptionある可能性のある低レベルを考えてみましょう。これは、正当な実行時エラーではなくコードのバグを示す傾向があるためです。ああ、はい。またNullReferenceException、NullReferenceExceptionからSystemException直接派生することを除いて、キャッチする（またはキャッチしない）すべての「論理エラー」を配置できるバケットはありません。

その後 IMNSHOあり、主要な持つのやりそこなうSEHException（経由導出ExternalException）SystemExceptionので、それが「通常の」作るSystemExceptionあなたが得るときSEHException、あなたはダンプを書き込むとすることができますように早く終了したい- .NET 4で始まるとは、少なくとも一部 SEH例外は、キャッチされない破損状態の例外と見なされます。良いことであり、CA1031ルールがさらに役に立たないという事実catch (Exception)です。これは、あなたの怠け者がとにかくこれらの最悪のタイプをキャッチしないからです。

次に、他のフレームワークのものがException直接または経由で一貫性なく派生SystemExceptionしているようで、重大度のようなものでキャッチ節をグループ化しようとします。

氏リペットによって曲ありますC#名声は、と呼ばれる難問の例外、彼は例外のいくつかの有用な分類をレイアウト、：あなたは、あなただけを除いて、「外因性」のものをキャッチしたいと主張でき... C#言語と.NETのデザインフレームワークの例外により、簡潔な方法で「外生的なもののみをキャッチ」することができなくなります。_{（そして、例えば、OutOfMemoryExceptionあり非常によく何とか大きいバッファを割り当てなければならないAPIのための完全に正常な回復可能なエラーです）}

私にとっては一番下の行は、ということ、である道C#のcatchブロックが仕事とフレームワークの例外階層が設計された方法は、ルールがCA1031全く役に立たを超えています。それはふり「例外を飲み込むていない」の根本問題を支援することではなく、例外を飲み込むと、あなたがキャッチ何を行うには、ゼロを持っていますが、あなたは何をして、その後の操作を行います。

あり、少なくとも 4つの方法合法的にキャッチを処理するためにはException、とCA1031のみ（すなわち再投ケース）表面的にそれらのいずれかを扱うようです。

注意点として、呼ばれるC＃6の特徴があります例外フィルターになりますCA1031、あなたは正しく、正しく、適切にあなたがキャッチしたい例外をフィルタリングし、フィルタリングされていないの書き込みに少ない理由がありますすることができるようになりますので、再度、もう少し有効にcatch (Exception)。

ポケモン例外処理（gotta catch em all！）は、必ずしも悪いわけではありません。メソッドをクライアント、特にエンドユーザーに公開するときは、アプリケーションをクラッシュさせたり焼き付けたりするよりも、何でもすべてをキャッチした方がよい場合がよくあります。

一般的には、できる限り避けるべきです。例外の種類に基づいて特定のアクションを実行できない限り、例外を飲み込んだり、誤って処理するのではなく、例外を処理せず、例外をバブルアップさせる方がよいでしょう。

詳細については、この SOの回答をご覧ください。

一般的な例外をキャッチすると、プログラムが未定義の状態のままになるため、悪いです。どこで問題が発生したかわからないので、プログラムが実際に何をしたか、または何をしていないかがわかりません。

すべてをキャッチできるのは、プログラムを閉じるときです。それをきれいにできる限り。閉じたプログラムほど迷惑なことはありません。エラーダイアログが表示されるだけで、そこに座っているだけで、離れずにコンピューターが終了するのを防ぎます。

分散環境では、ログメソッドが裏目に出る可能性があります。一般的な例外をキャッチすると、プログラムがログファイルのロックを保持しているため、他のユーザーがログを作成できなくなります。

この規則の根拠を理解しています。しかし、実際には、スローされた例外に関係なく同じアクションを実行したい場合、それぞれを具体的に処理するのはなぜですか？

他の人が言ったように、スローされた例外に関係なく実行したいアクションを想像することは（不可能ではないにしても）本当に難しいです。ほんの一例は、プログラムの状態が破損しており、それ以上の処理が問題を引き起こす可能性がある状況です（これは背後にある理論的根拠ですEnvironment.FailFast）。

さらに、特定の例外を処理する場合、呼び出しているコードが変更されて将来新しい例外がスローされるとどうなりますか？次に、その新しい例外を処理するためにコードを変更する必要があります。一方、単に例外をキャッチした場合、コードを変更する必要はありません。

趣味のコードの場合はキャッチしても問題Exceptionありませんが、新しい例外タイプを導入するプロ級のコードの場合は、メソッドシグネチャの変更と同じ点で処理する必要があります。この観点にサブスクライブする場合、クライアントコードの変更（または検証）に戻ることが唯一の正しい行動であることはすぐに明らかです。

たとえば、FooがBarを呼び出し、FooがBarによってスローされた例外のタイプに関係なく処理を停止する必要がある場合、キャッチしている例外のタイプを特定することに利点はありますか？

確かに、によってスローされBarた例外だけをキャッチするわけではないからです。また、BarのクライアントまたはランタイムでさえBar、コールスタック上にある間にスローする例外があります。作成Bar者は、必要に応じて独自の例外タイプを定義する必要があります。これにより、呼び出し元は、自分で発行した例外を明確にキャッチできます。

では、OutOfMemoryException以外のすべての例外を無視したい場合はどうすればよいでしょうか？

私見これは例外処理について考える間違った方法です。ブラックリスト（X以外のすべての例外をキャッチ）ではなく、ホワイトリスト（例外タイプAおよびBをキャッチ）を操作する必要があります。

たぶん。すべてのルールには例外があり、ルールに無批判に従うことはできません。あなたの例では、可能性が考えられることは、すべての例外を飲み込むことは理にかなってインスタンスの一つです。たとえば、重要な実稼働システムにトレースを追加する場合、変更によってアプリのメインタスクが中断されないことを確実に確認したい場合です。

ただし、失敗の原因をすべて黙って無視する前に、考えられる失敗の理由について慎重に検討する必要があります。たとえば、例外の理由が次の場合はどうなりますか？

• 常に特定の例外をスローするロギングメソッドのプログラミングエラー
• 構成内のログファイルへの無効なパス
• ディスクがいっぱいです

この問題が存在することをすぐに通知したくないので、修正できますか？例外を飲み込むことは、何かがうまくいかなかったことを決して知らないことを意味します。

一部の問題（ディスクがいっぱいなど）によって、アプリケーションの他の部分が失敗することもありますが、この失敗は現在ログに記録されていないため、わかりません！

技術的な観点ではなく論理的な観点からこれに対処したいと思います。

次に、その新しい例外を処理するためにコードを変更する必要があります。

まあ、誰かがそれを処理する必要があります。それがアイデアです。ライブラリコードの作成者は、新しい例外タイプを追加することを慎重に考えますが、クライアントが破損する可能性があるため、これを頻繁に発生させることはありません。

あなたの質問は基本的に「何が間違っているのか気にしないとしたら、それが何だったのかわからないのですか？」ということです。

ここに美しさの部分があります：いいえ、あなたはしません。

「それで、私はただ他の見方をして、どんな厄介なものが現れても自動的にカーペットの下に流されて、それで終わらせることができますか？」

いいえ、それは動作しません。

ポイントは、可能な例外のコレクションは常に期待するコレクションよりも大きく、ローカルの小さな問題のコンテキストに関心があるということです。予期したものを処理し、予期しないことが発生した場合は、それを飲み込むのではなく、より高いレベルのハンドラーに任せます。予期しない例外を気にしない場合は、コールスタックの誰かを賭けます。ハンドラーに到達する前に例外を強制終了するのは妨害になります。

「しかし...しかし...私が気にしない他の例外の1つは私のタスクを失敗させる可能性があります！」

はい。ただし、それらはローカルで処理されるものよりも常に重要です。火災警報器や上司があなたがしていることをやめて、現れたより緊急のタスクを拾うように言っているように。

すべてのプロセスの最上位で一般的な例外をキャッチし、バグを可能な限り報告し、プロセスを終了することで処理する必要があります。

一般的な例外をキャッチして実行を継続しないでください。