7

とにかく例外をスローするだけの場合に、到達できない break ステートメントを残すのはばかげていますか? 私の防御的な部分は、ロジックが変更された場合に備えて残しておきたいと考えています。私の別の部分では、他の開発者が自分のコードでコンパイラの警告 (「到達不能なコードが検出されました」) を見ることを望んでいません。

switch (someInt)
{
    case 1:
        // Do something
        break;
    case 2:
        // Do something else
        break;
    case 3:
        // Oh, we don't use threes here!
        throw new Exception("Business rules say don't use 3 anymore");
        break; // Unreachable...until the fickle business rules change...
    default:
        throw new Exception("Some default exception");
        break; // Unreachable...until...well, you get the idea.
}

何をすべきか？

アップデート

後日スローを削除するとコンパイラエラーが発生するという回答がいくつかあります。ただし、単にスローを削除 (またはコメント) し、その後に中断を加えないと、ケースがスタックされ、意図しない動作になる可能性があります。私はそれがありそうなシナリオだと言っているわけではありませんが...まあ、ありそうなシナリオだけと戦うことについての防御的なプログラミングですか?

4

9 に答える 9

7

それらを削除します。いくつかの理由：

  • 現時点では必要ありません
  • このタイプの警告から来るノイズで実際の警告を失う可能性があるため、多くの警告を見ると常に緊張します（エラーとして警告したと仮定します）。
于 2012-03-29T21:57:23.820 に答える
7

で「隠す」ことはしませんswitch。ArgumentExceptionsできるだけ早く投げます。これにより、副作用が回避され、透明性も向上します。

誰かがスイッチの前にコードを追加するかもしれませんがsomeInt、それは 3 ですが使用します。

例えば：

public void SomeMethod(int someInt)
{
    if (someInt == 3)
        throw new ArgumentException("someInt must not be 3", "someInt");

    switch (someInt)
    {
        // ...
    }
}
于 2012-03-29T21:59:36.110 に答える
2

一部のコンパイラ警告を無視することで、コンパイラ警告を無視するという悪い動作を強化しています。break私の意見では、それはあなたがステートメントを残すことから得られるどんな利点よりも大きなリスクです。

編集：breakステートメントを削除する場合は、コンパイラーについての元のポイントを削除して、ステートメントを元に戻すように強制しthrowました。payoが指摘したように、場合によっては、コンパイラーはそうしませんでした。ケースとその下のケースを組み合わせるだけです。

于 2012-03-29T21:57:38.210 に答える
2

個人的には、到達不能コードを本番コードに残すことは決してありません。テストには問題ありませんが、そのままにしないでください。

あなたはこれを決してしませんか？

public void MyMethodThatThrows()
{
    throw new Exception();
    return;  // unneeded
}

では、なぜ保持するのbreakですか？

于 2012-03-29T21:58:21.750 に答える
1

削除します。

警告が削除され、ロジックが変更されて例外が削除された場合でも、ブレークを追加し直す必要があるというコンパイラエラーが表示されます。

于 2012-03-29T21:57:18.737 に答える
0

私の防御的な部分は、ロジックが変更された場合に備えて、そこに残したいと思っています。

を削除してコンパイラthrowを追加するのを忘れた場合はbreak、コンパイラが通知します。

休憩がそこにある理由はわかりません。これは冗長であり、とにかく警告をトリガーするだけなので、削除します。ロジックを乱雑にするために役に立たないコードを残す理由はありません。

于 2012-03-29T21:57:02.527 に答える
0

私の防御的な部分は、ロジックが変更された場合に備えて残しておきたいと考えています。

ここで正確にどのロジックが変更される可能性がありますか? 例外がスローされたときに何が起こるかについては、かなり詳しく文書化されています。そして、C# の今後のリビジョンが、「これまでに作成されたすべてのプログラムが機能しなくなった」という重大な変更に影響を与えることはないと、十分に確信できると思います。

コンパイラの警告がなかったとしても、定期的なメンテナンス中にバグを防ぐことによってコードが機能する可能性がない限り、冗長なコードは良いことではありません。この場合、そのような可能性が存在すると合理的に言うことはできません.

于 2012-03-29T21:56:36.177 に答える
0

MSDN C# リファレンスには、次のように記載されています。

それで、「投げる」は「ジャンプ文」を構成しませんか？そうだと思います。したがって、「中断」は必要なく、「到達不能」の問題は解消されます。:)

于 2013-05-03T21:01:42.863 に答える