何時適合使用錯誤代碼？

Question

在支持異常對象（Java，C＃）的語言中，何時適合使用error codes？在典型的企業應用程序中是否使用錯誤代碼？

許多着名的軟件系統都使用錯誤代碼（以及相應的錯誤代碼參考）。一些示例包括操作系統（Windows），數據庫（Oracle，DB2）和中間件產品（WebLogic，WebSphere）。錯誤代碼提供了什麼好處？使用錯誤代碼有什麼缺點？

Answer 1

WITHIN一個程序應該總是使用異常而不是錯誤代碼。但是，異常不能傳播到程序之外。任何時候錯誤都必須離開程序，並留下錯誤信息或錯誤代碼。

對於簡單的事情，將永遠是人爲操作的錯誤消息沒有代碼是好的。你可以說「沒有找到文件」而不給它一個錯誤代碼。但是，如果它可能是另一端的另一臺計算機，則應另外給出錯誤代碼。當您將其更改爲「未找到文件<x>」時，您不想打破其他系統。

Answer 2

錯誤代碼是老派。他們根本沒有價值。

錯誤代碼唯一可能的值是它可以識別一個非常特定的情況。您可以爲代碼庫中的每個點添加一個可以拋出異常的代碼。這將使您能夠非常精確地縮小問題的嚴重程度。

但是沒有人關心這個詳細程度。誰想要維持這樣的混亂。它會給你留下類似「由於狀態S而導致的條件A和B但不是C」的代碼。試圖弄清楚這到底意味着什麼，而不是努力工作。堆棧跟蹤將更有價值地告訴你程序中發生問題的位置。

我學會了編程計算機之前，例外是一種普遍的技術。我是所以很高興我們得到例外！

Answer 3

我不認爲我曾經用在.net中的錯誤代碼，除非一個情況 - 當我創造，我知道將要被從其他應用程序稱爲一個控制檯應用程序。這個其他的應用程序必須知道控制檯應用程序何時失敗，以及出了什麼問題。所以，一個適當的例子是，當你知道你的程序將被其他程序調用，並且你想要一個結構化的方式來讓他們理解錯誤。

這就是說，我當時是.NET的新手，並且從未使用錯誤代碼。

作爲一個側面說明，作爲一個Windows用戶，能夠在錯誤代碼中填充並提供知識庫文章是很好的，所以錯誤代碼與良好的文檔和找到它的能力相結合=好的感覺來自您的用戶。

Answer 4

當錯誤需要傳達給用戶時，我經常使用錯誤代碼，因爲它們可以國際化。例如，在編譯器中，如果用戶代碼中存在錯誤，則可以在編譯器後端發送錯誤信息，而前端可以將它們本地化爲文化/語言特定的字符串以供用戶使用。然而，對於這個目的，枚舉可能比原始整數更好。

我也用它們爲應用程序創建「錯誤報告」框架。當拋出異常時，它們被拋出一個錯誤代碼，當異常冒出時，它被髮送（通過日誌）到中央服務器。該代碼幫助組織數據庫，以便我們可以檢查與特定錯誤相關的日誌。

最後，在其他幾個答案中提到，錯誤代碼是容易和語言無關的谷歌（認爲Windows錯誤代碼/ MS KB文章），這樣的錯誤代碼與的什麼地方出了錯可能是一個描述更適合技術產品的最終用戶。

錯誤代碼的想法是有用的，但IMO它們屬於異常成員或作爲IErrorReporter接口的參數或更多東西而不是方法返回值。

Answer 5

Web服務界面非常普遍。返回帶描述的代碼非常簡單且標準。

我同意大多數情況下的是老派

我會說這是代碼的質量最大的缺點。您必須添加更復雜的邏輯來管理錯誤代碼，而不必使用方法參數或返回值就會發生異常。

您還必須添加一個「IF」來檢查返回的代碼是否成功，而異常直接發送到錯誤處理塊。

Answer 6

C＃和可能Java也支持更好的異常處理控制流，finally關鍵字，這使得事情比使用錯誤代碼更好一點。一個異常對象可以包含任何級別的細節，當然遠不止一個錯誤代碼。因此，異常對象更實用，但是您可能遇到一個不常見的情況，其中錯誤代碼會更合適。

FWIW，C++也支持異常對象。我不認爲C++支持finally關鍵字（雖然可能更新的C++ whatevers），但在C++中，您還必須避免在catch處理程序中返回等內容。

Answer 7

我是一個新手，堆棧溢出，但...

我相信，錯誤代碼往往使用或處理需要各種各樣的最終用戶錯誤的情況下非常有用涉足到整頓情況。如果您的代碼要由其他開發人員維護，那麼異常就是要走的路。然而，在一個情況下有一個問題：

• 環境

  您的應用程序正在運行

• 與您的應用程序和其他一些實體（Web服務器，數據庫，插座等）之間的通信

• ，一個設備或設備驅動程序指示（硬件故障也許？）

然後錯誤代碼可能是有意義的。例如，如果您的應用程序試圖代表最終用戶登錄數據庫，但數據庫無法進行身份驗證（數據庫脫機，電纜被拔出），則錯誤代碼/說明組合可能有助於終端用戶訪問數據庫，用戶解決問題。

再次在開發人員/工程師級別，他們可以觸摸源代碼（傳統調試和測試技術）並對其進行修改，使用例外。

希望這有助於...

--jqpdev

Answer 8

我已經寫了由其他（遠程）應用程序佔用很多的網絡服務。當請求發生嚴重錯誤時，客戶或多或少地堅持要獲取代碼，以便他們不必進行可怕的字符串比較以找出錯誤。

採取HTTP結果代碼爲這樣的行爲的一個很好的例子。 「200」意味着快樂，「300」可以任何一種方式，「400」或「500」意味着開始瘋狂。

Answer 9

錯誤代碼被設計在這樣一個時代，一個函數告訴出事了來電者的唯一途徑是特殊的意義分配給其中的一個或多個值可以返回，並非常頻繁只本地整數左右可用於返回該特殊值。

例如，在C「得到字符」例行程序返回的下一個字符的ASCII值，但返回如果由於某種原因出現了問題負值。然後，您負責以某種方式返回給您的主叫方，以便可以處理此錯誤情況，並且必須返回等。

異常機制是處理此問題的優雅方法「這是一個緊急情況，我們必須從直到能夠解決問題爲止「。錯誤代碼不如此。

Answer 10

錯誤代碼是，如果你想將它們發送給用戶。如果不是，請使用例外。