私は例外をスローする場合に到達不能な休憩を残すべきですか？

Question

例外をスローするケースに到達できないブレークステートメントを残すのは私の愚かなことですか？私の守備的な部分は、論理が変わった場合にそこに残したいと思っています。私の別の部分は、他の開発者が自分のコードでコンパイラの警告を見るのを望んでいません（ "Unreachable code detected"）。

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. 
} 

UPDATE

私は後日スローを削除するとコンパイルエラーを引き起こすだろうと言って、いくつかの回答を参照してください。しかし、単純にスローを取り除く（またはコメントする）だけでは、それを破棄することなくケースをスタックすることになり、意図しない振る舞いになる可能性があります。私はそれが起こりそうなシナリオだと言っているわけではないが...まあ、可能性の高いシナリオとの戦いについて防御的なプログラミングですか？

Answer 1

私は」それらを取り除く。いくつかの理由：あなたはエラーとして警告していると仮定すると（警告このタイプからのノイズの本当の警告を失うことができるよう

• あなたは
• は警告の多くを見た瞬間にそれらを必要としませんが、常に私を神経質になりますオフ）。

Answer 2

ロジックが変更された場合、私の守備側はそこに残したいと思っています。

正確なロジックはここで変更されることがありますか？例外がスローされたときに起こることは、かなりうまく文書化されています。そして、あなたは、C＃への後のリビジョンが "これまでに書かれたすべてのプログラムはもはや働いていません"という大きさの変更に影響しないことは合理的に確信できると思います。

コンパイラの警告がなくても、定期的なメンテナンス中にバグが発生する可能性がない限り、冗長コードは有効ではありません。この場合、このような可能性は合理的には言えません存在する。

Answer 3

私の守備的な部分は、ロジックが変わった場合にそこに残したいと思っています。

throwを削除して、breakを追加することを忘れた場合は、コンパイラがお知らせします。

休憩がある理由はありません。それは冗長で、とにかく警告を発するだけなので、私はそれを削除します。あなたのロジックを混乱させるような無用なコードを残す理由はありません。

Answer 4

削除します。

これは、警告を取り除くと、論理が変化したと例外を削除する場合でも、あなたはブレークに戻って追加する必要があるというコンパイラエラーを受け取るだろう。

Answer 5

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

EDIT：私はthrow文が削除された場合、バックでbreak文を入れて、あなたを強制的にコンパイラについての私の原点を削除しました。 payoが指摘するように、場合によっては、コンパイラはそうではないでしょう。それはちょうどそれをその下のものと組み合わせるだろう。

Answer 6

個人的に、私は決して生産コードに到達できないコードを残すことはありません。テストのためには問題ありませんが、テストのままにしないでください。

あなたはこれを行うことはありませんか？

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

だから、なぜbreakを保持しますか？

Answer 7

私はswitchに「隠す」ことはできません。私はできるだけ早くArgumentExceptionsを投げます。それは副作用を避け、さらに透過的です。ことを、私は私のプロジェクトのソースはとてもクールとトラブルレスなあ

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

    switch (someInt) 
    { 
     // ... 
    } 
} 

Answer 8

：

誰かがそれが例えば3

ですがsomeIntを使用していくつかの点でスイッチの前にコードを追加することができます私は防衛プログラミングのそのような小さなケースについて考える必要があります:)

私は、ソフトウェア開発にはCOMとInterop、セキュリティ/アクセス許可と認証、証明書、so-oo多くの落とし穴があることを意味する... gosh 、方法を教えてくれない私は足での射撃から自分を守るために書く必要があります。

これは重複しているため、「ケース」がbreakまたはreturnで終わっていることを知っている仲間にとって紛らわしく、このことを知らないフェローにとって明らかになるはずです。

Answer 9

MSDN C# Referenceは、「最後のブロックがcase文であるかdefault文であるかを含めて、各caseブロックの後に改行などのジャンプ文が必要です。

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