拋出異常時，沒有指定的情況下，可以處理

Question

比方說，我們有一個在MVC應用程序：

public JsonResult ChangePassword 
    (string username, string currentPassword, string newPassword) 
{ 
    switch (this.membershipService.ValidateLogin(username, currentPassword)) 
    { 
     case UserValidationResult.BasUsername: 
     case UserValidationResult.BadPassword: 
      // abort: return JsonResult with localized error message   
      // for invalid username/pass combo. 
     case UserValidationResult.TrialExpired 
      // abort: return JsonResult with localized error message 
      // that user cannot login because their trial period has expired 
     case UserValidationResult.Success: 
      break; 
    } 

    // NOW change password now that user is validated 
} 

membershipService.ValidateLogin()返回UserValidationResult枚舉改變了用戶的密碼系統中的一個函數，被定義爲：

enum UserValidationResult 
{ 
    BadUsername, 
    BadPassword, 
    TrialExpired, 
    Success 
} 

作爲一個防禦性的程序員，我會改變上述ChangePassword()方法拋出一個異常，如果有一個無法識別的UserValidationResult值從ValidateLogin()回：

public JsonResult ChangePassword 
    (string username, string currentPassword, string newPassword) 
{ 
    switch (this.membershipService.ValidateLogin(username, currentPassword)) 
    { 
     case UserValidationResult.BasUsername: 
     case UserValidationResult.BadPassword: 
      // abort: return JsonResult with localized error message   
      // for invalid username/pass combo. 
     case UserValidationResult.TrialExpired 
      // abort: return JsonResult with localized error message 
      // that user cannot login because their trial period has expired 
     case UserValidationResult.Success: 
      break; 
     default: 
      throw new NotImplementedException 
       ("Unrecognized UserValidationResult value."); 
      // or NotSupportedException() 
      break; 
    } 

    // Change password now that user is validated 
} 

我一直認爲模式就像最後一個片段的最佳實踐。例如，如果一個開發人員現在要求用戶嘗試登錄時要求，如果出於這種或那種商業原因，他們是否會首先聯繫業務？所以UserValidationResult的定義更新爲：

enum UserValidationResult 
{ 
    BadUsername, 
    BadPassword, 
    TrialExpired, 
    ContactUs, 
    Success 
} 

開發商改變了ValidateLogin()方法的身體恢復新枚舉值（UserValidationResult.ContactUs）適用的時候，卻忘記更新ChangePassword()。在交換機中沒有例外的情況下，用戶仍然可以在他們的登錄嘗試甚至不需要首先驗證時更改密碼！

難道只是我，或者是這default: throw new Exception()一個好主意嗎？我幾年前就看到了它，並且始終（在通過它之後）認爲這是最佳做法。

Answer 1

我總是拋出一個異常，在這種情況下。考慮使用InvalidEnumArgumentException，在這種情況下可以提供更豐富的信息。

Answer 2

跟你有什麼是好的，雖然break語句後，它永遠不會被擊中，因爲當一個異常被拋出未處理該線程的執行將停止。

Answer 3

我從來不會在switch語句中包含的throw語句之後添加中斷。不用擔心的是煩人的「檢測不到的代碼」警告。所以是的，這是一個好主意。

Answer 4

我覺得這樣的做法是非常有用的（例如，見Erroneously empty code paths）。如果你可以在釋放的代碼中編譯默認值，比如assert，那更好。這樣在開發和測試過程中就有了額外的防禦性，但在發佈時不會產生額外的代碼開銷。

Answer 5

你說你非常防守，我可能會說這太過分了。其他開發者是不是要測試他們的代碼？當然，當他們做最簡單的測試時，他們會看到用戶仍然可以登錄 - 所以，他們會意識到他們需要修復的東西。你所做的並不可怕或不對，但如果你花了很多時間去做，那可能太過分了。

Answer 6

我總是喜歡做的正是你所擁有的，雖然我平時拋出ArgumentException，如果它是在傳遞一個說法，但我挺喜歡NotImplementedException更好，因爲錯誤可能是一個新的case語句應該是相當添加比調用者應該將參數更改爲支持的參數。

Answer 7

枚舉的生活時，「遠」，從它的使用，但在枚舉是非常接近並專用於特定功能的情況下，好像有點多，我曾經使用過這種做法的具體實例。

很可能，我懷疑調試斷言失敗可能更合適。

http://msdn.microsoft.com/en-us/library/6z60kt1f.aspx

注意第二個代碼示例...

Answer 8

對於一個Web應用程序，我寧願使用默認方式生成結果並顯示一條錯誤消息，要求用戶聯繫管理員並記錄錯誤，而不是引發可能導致用戶意義不大的異常。因爲我可以預測，在這種情況下，返回值可能不是我期望的，我不會認爲這是真正的特殊行爲。

而且，導致額外的枚舉值你的使用情況不應該引入一個錯誤，您的特定方法。我的期望是該用例僅適用於登錄 - 這可能會在ChangePassword方法可以合法調用之前發生，大概是因爲您想在更改密碼之前確保該用戶已登錄 - 您應該實際上從來沒有將ContactUs的值作爲密碼驗證的返回值。該用例將指定如果聯繫結果返回，則認證失敗，直到結果條件被清除。如果不是這樣，我希望你會對系統的其他部分應該如何在這種情況下作出反應有所要求，並且你會編寫測試來強制你改變這個方法中的代碼以符合這些測試，處理新的返回值。

Answer 9

驗證運行的制約通常是一件好事，所以是的，最好的做法，以「快速失敗」的原則幫助和檢測到錯誤條件時，而不是繼續默默地你停止（或記錄）。有些情況並非如此，但給予switch語句，我懷疑我們沒有經常看到它們。

要精心，switch語句總是可以通過if/else語句塊替換。從這個角度看它，我們看到了扔VS在默認開關的情況下不要亂扔大約相當於這個例子：

if(i == 0) { 


    } else { // i > 0 


    } 

VS

if(i == 0) { 


    } else if (i > 0) { 


    } else { 
     // i < 0 is now an enforced error 
     throw new Illegal(...) 
    } 

第二個例子通常被認爲是因爲更好如果違反了錯誤約束而不是在潛在的錯誤假設下繼續執行，則會失敗。

相反，如果我們想：

if(i == 0) { 


    } else { // i != 0 
     // we can handle both positve or negative, just not zero 
    } 

然後，我懷疑在實踐中最後一種情況下可能會顯示爲一個if/else語句。因爲switch語句經常類似於第二個if/else塊，所以通常是最佳實踐。

一些更多的考慮是值得的： - 考慮多態的方法或枚舉的方法來完全取代switch語句，如：Methods inside enum in C# - 如果拋是最好的，在其他的答案注意到喜歡使用一個特定的異常鍵入避免鍋爐板代碼，例如：InvalidEnumArgumentException