異常或錯誤代碼枚舉

最近我重構將使用專用USB設備中的.NET程序。該設備帶有一個DLL通信。該DLL用c編寫，通過檢查頭文件，它定義了一組錯誤返回碼。異常或錯誤代碼枚舉

與設備通訊的第一步是打開設備。

在DLL，open函數如下：

// return different codes, such as OK, ERROR_CANNOT_CLAIM_INTERFACE, etc. 
int DLL_Open();

在.NET程序，它使用了錯誤代碼例外：

// Return true if succeed. Throw exception if there is error. 
bool Open() 
{ 
    int flag = DLL_Open(); 
    if(flag == OK) return true; 
    else 
    { 
     if(flag == ERROR_CANNOT_CLAIM_INTERFACE) 
      throw USBException(); 
     // ... 
    } 
}

我的問題是，爲什麼要使用異常，而不是簡單地使用錯誤代碼作爲dll API？我讀提到「不要使用異常來控制應用程序流」的一些文章，我覺得這裏的例外是那種喜歡控制流量。

來源

2009-11-25 AZ.

這兩個解決方案都可以工作，枚舉提供更好的性能和異常，可以提供更好的解耦（跨系統邊界）。這實際上是軟件設計和約定的問題。如果您正在使用的系統的功能範圍不包括處理給定的錯誤條件，則基本上使用異常。

如果這個.NET程序有它自己的用戶界面，你不需要拋出異常。使用枚舉並向用戶顯示錯誤。在另一方面，如果這個.NET程序是由第三方使用的組件，它被認爲是更傳統的不暴露錯誤代碼或枚舉的API中，而是扔（和文件）例外。

的中間地帶將是這個程序沒有它自己的用戶界面，但它是由你也（或者有人在你的組織中）具有控制另一臺系統消耗。在這種情況下，你可以採用任何方式，枚舉提供更好的性能，異常提供更好的解耦。

來源

2009-11-25 19:15:49

返回碼不影響執行流程。您可以自由地忽略返回代碼，而必須主動捕獲和忽略異常。

我會做異常的使用，其中一些足夠糟糕的事情，這樣你可以沒有一些補救措施使用該組件攜帶（或子組件等）- 在這種情況下，插入USB棒。

這是控制程序流？顯然是（如有任何例外）。但是一個有效的問題是如何特殊的是這個？

來源

2009-11-25 19:07:00

異常是一種體面的處理錯誤的方式，你可以使用其他形式（例如：GOTO），但它不好。我也不會與不使用它做控制流......顯然，我說的流動是一個非常低的入侵流量，你應該艾琳的所有基於異常的決策zilions的想法一致，但可以定義不同行動和流程取決於某些特例。也就是冒泡錯誤的好辦法。

來源

2009-11-25 19:07:51 Oakcool

這歸結爲一個非常簡單的問題：它是典型的程序流程嗎？

你不希望你的代碼的標準條件邏輯被異常控制，但另一方面，如果它是一個真正的錯誤情況則拋出適當類型的例外是最好的一段路要走。它確實涉及事件是否是調用函數的預期結果或罕見的邊緣錯誤。有時甚至是有意義的做到這一點，將預期的結果作爲枚舉暴露出來，但仍然將實際錯誤作爲例外情況。

從性能角度來看，異常模型使用的處理能力更強大，但只有在引發異常時纔會如此。如果沒有錯誤，實際上比使用枚舉更快。如果你真的想看看這個表現，那麼尋找關於Int32.Parse和Int32.TryParse的信息可能有最多的信息（第一個使用異常模型，他們增加了第二個以提高性能，因此人們經常使用它未驗證的數據）。

來源

2009-11-25 21:25:37 fyjham

爲什麼要使用異常而不是簡單地使用錯誤代碼作爲dll API？

沒有理由在本例中使用異常。

只需從Open方法返回enum OpenResult { Openned, DLLFailed }方法。對於Open方法的調用者來說，這足以瞭解發生了什麼並據此採取行動。

來源

2015-08-30 11:17:35 Lightman

異常或錯誤代碼枚舉

回答

相關問題