我應該在拋出異常的情況下留下不可達的中斷嗎？

無論如何拋出一個異常的情況下離開無法到達的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. 
}

怎麼辦？

UPDATE

我看到一些答覆說，在以後的日子取出扔會導致編譯器錯誤。然而，簡單地刪除（或註釋）拋出之後不會中斷，會疊加這些情況，這可能是非預期的行爲。我並不是說這是一種可能的情況，但是......呃，防禦性的編程只關於可能的情況？

來源

2012-03-29 Tim Lehner

'break'不再需要，我將它們刪除，因爲我將警告作爲錯誤進行構建。 – asawyer 2012-03-29 21:56:30

有趣的問題 - 我最初的反應是包含break語句，但我認爲這完全歸結於習慣。 – KazR 2012-03-29 21:59:15

編譯指示警告禁用，如果你覺得你的擔心是有效的，但不想給別人帶來不便，但是過分防禦可能會迅速混亂你的代碼庫 – Michael 2012-03-29 22:09:23

我d刪除它們。有幾個原因：

你並不需要他們的時刻
看到許多警告，總是讓我緊張，因爲你可能會失去從這個類型的警告傳來的噪音真實警告（假設你有警告的錯誤關閉）。

來源

2012-03-29 21:57:23 gbanfill

你會如何錯過「真正的錯誤？」無論是你的代碼不會編譯，或者你已經決定警告不是一個「真正的錯誤」（即你不用「將警告視爲錯誤」標誌）。 – Michael 2012-03-29 22:02:47

如果您在上面生成了150條警告，並且您引入了一些會生成有用警告的內容，則很容易錯過。 – gbanfill 2012-03-29 22:04:38

我的防禦部分想要在邏輯改變的情況下離開它。

確切的邏輯在這裏可以改變嗎？當引發異常時會發生什麼記錄非常好。而且我認爲你可以合理地確信，以後對C＃的修改不會影響到「迄今爲止編寫的所有程序都不再有效」的重大改變。

即使沒有編譯器警告，冗餘代碼也不是一件好事，除非代碼可能在日常維護過程中通過防止錯誤發揮作用，在這種情況下我們不能合理地說這種可能性存在。

來源

2012-03-29 21:56:36 Jon

我認爲他的意思是如果異常被移除，但即使這樣也不是問題因爲你必須有一個或另一個。 – 2012-03-29 21:57:26

也許我在那裏使用了錯誤的術語，但是不，我並不是說如果C＃規範發生變化，只會變幻無常的業務規則。 – 2012-03-29 22:10:51

在邏輯改變的情況下，我的防守部分想讓它留在那裏。

那麼，如果你刪除了throw並忘記添加一個break編譯器會讓你知道。

我看不出有什麼理由讓休息時間到來。這是多餘的，你只會觸發一個警告，所以我會刪除它。沒有充分的理由讓你的邏輯混亂無用的代碼。

來源

2012-03-29 21:57:02

簡單地刪除沒有中斷的投擲將堆疊案件，這可能是意外的行爲。 – 2012-03-29 22:03:27

@TimLehner：這是真的，因爲身體是空的。這就是說...如果你把身體留空了，那麼我認爲你這樣做是有原因的。我希望你能相信你的同事知道交換機工作的基本知識。 – 2012-03-29 22:07:32

難道我們都不希望有同樣的事情嗎？ :) – 2012-03-29 22:08:08

我想刪除它。

它擺脫了警告，即使邏輯要改變和被刪除的異常，你會收到一個編譯器錯誤說，休息需要添加回來。

來源

2012-03-29 21:57:18 Brandon

不僅僅是一個警告，它會是一個錯誤。 – 2012-03-29 21:58:07

@EdS，你說的對，我的錯。 – Brandon 2012-03-29 21:58:38

其實有一種情況我們都是錯的。如果異常被移除並且沒有添加任何內容，那麼主體將是空的，並且允許在沒有警告或錯誤的情況下通過。 – 2012-03-29 22:08:16

通過忽略一些編譯器警告，您正在強化忽略任何編譯器警告的不良行爲。在我看來，這比在離開break報表時所獲得的優勢更大。

編輯：我刪除了關於編譯器迫使你把break語句回如果throw聲明是要刪除我原來的觀點。正如Payo指出的那樣，在某些情況下，編譯器不會。它只是將案例與下面的案例結合起來。

來源

2012-03-29 21:57:38 FishBasketGordo

如果案例沒有其他代碼（在評論throw後），編譯器不會強制您添加中斷。 – payo 2012-03-29 22:26:01

你說得對。在這種情況下，程序員有責任編寫好的代碼。 – FishBasketGordo 2012-03-30 15:03:31

就我個人而言，我永遠不會在生產代碼中留下無法訪問的代碼。測試很好，但不要這樣做。

你永遠不會這樣做嗎？

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

so so keep the break？

來源

2012-03-29 21:58:21

我瞭解這口井的第一部分，這是一個很好的觀點。然而，這個例子有點像稻草人，因爲雖然我不會把一個回報放在一個空白內，但我肯定會在一個開關內部留下一些空隙。當然，這個問題是關於休息而不是交換中的回報，因爲我是一個退出類型的人。 – 2012-03-30 04:26:22

@TimLehner，哈，好點。我的例子基本上只是誇大了這個問題。 – 2012-03-30 05:22:15

我不會「隱藏」它在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-29 21:59:36

極好的點和一個偉大的代碼氣味。 – 2012-03-30 04:29:42

我希望我的項目源代碼是如此冷靜和故障少，即我不得不考慮這樣的小規模防禦性編程:)

我的意思是在軟件開發中存在許多缺陷 - COM和Interop，安全/權限和身份驗證，證書，......天哪，不能告訴你如何我必須寫很多代碼來保護自己免於在腳下射擊。

只是刪除這個休息時間，因爲它是多餘的，對於知道'案件'應該以break或return結束並且應該對不知道這一點的同伴很明顯的同伴來說，這會讓人困惑。

來源

2012-03-29 22:51:22

沒錯，這不是人生中最大的問題。現在，以回報結束的案件絕對有爭議...... – 2012-03-30 04:39:55

MSDN C# Reference states：「在每個大小寫塊之後都需要跳轉語句，例如中斷，包括最後一個塊，無論它是一個case語句還是一個默認語句。」

那麼，不是「扔」構成了「跳躍聲明」？我認爲它確實如此。因此，不需要「休息」，並且「不可達」問題消失。 :)

來源

2013-05-03 21:01:42

該OP承認，「休息」不是必要的，但正在考慮讓他們在防守端。考慮如果您決定除了拋出異常之外做其他事情會發生什麼。 – jerry 2013-05-03 21:31:14

我應該在拋出異常的情況下留下不可達的中斷嗎？

回答

相關問題