11

重複の可能性：
空のキャッチブロックが悪い考えであるのはなぜですか？
キャッチされた例外を無視する正当な理由はありますか

空のキャッチブロックが絶対的な悪ではない状況を知っていますか？

try
{
    ...
    // What and When?
    ...
}
catch { }
4

5 に答える 5

7

There are a lot of questions on this, try to look at:

Why are empty catch blocks a bad idea?

From that post's accepted answer:

Usually empty try-catch is a bad idea because you are silently swallowing an error condition and then continuing execution. Occasionally this may be the right thing to do, but often it's a sign that a developer saw an exception, didn't know what to do about it, and so used an empty catch to silence the problem.

It's the programming equivalent of putting black tape over an engine warning light.

于 2011-01-14T14:29:59.340 に答える
1

これを見てください。基本的に、発生する可能性のある例外の種類を4つのカテゴリに分類しますが、いずれも空のcatchブロックで処理する必要はありません。

于 2011-01-14T14:33:01.000 に答える
1

少なくとも、try {} に入力したものが例外をスローしたことを示す何らかのコメントまたはログに記録されたメッセージを提供する必要があると思います。これが、何もしていない理由です。

于 2011-01-14T14:33:43.500 に答える
1

ある種のbool TrySomething(out object)関数が必要な、またはobject TrySomething()基になる呼び出しが例外として他のメカニズムを提供しない、いくつかの自己記述ライブラリに使用しました。この場合、空の catch ブロックを使用してfalseorを返しnullます (関数のシグネチャによって異なります)。

空の catch ブロックを証明する例

public bool TrySomething(out object destination)
{
    try
    {
        destination = DoSomething();
        return true;
    }
    catch
    {}

    return false;
}
于 2011-01-14T14:34:49.040 に答える
1

公理：

空のキャッチブロックは絶対悪

これを回避する方法を見つけようとしないでください。絶対的な悪ではないケースを見つけようとするだけで、貴重な脳のサイクルを浪費していることになります。ここでパターンを見つけようとしないでください。「うーん、ここに空の catch ブロックを配置する必要がありますか?」

誰かのコードで空の catch ブロックに出くわした場合は、技術的負債に遭遇したことになります。修理する。空の catch ブロック内にロギング ステートメントを 1 つ追加するだけでも、この世界をより良い場所にすることができます。

于 2011-01-14T14:37:22.030 に答える