C代碼中的錯誤處理在C庫中以一致的方式處理錯誤處理錯誤時，您認為“最佳實踐”是什么？我一直在考慮兩種方式：始終返回錯誤代碼。典型的功能如下所示：MYAPI_ERROR getObjectSize(MYAPIHandle h, int* returnedSize);始終提供錯誤指針方法：int getObjectSize(MYAPIHandle h, MYAPI_ERROR* returnedError);使用第一種方法時，可以編寫這樣的代碼，其中錯誤處理檢查直接放在函數調用上：int size;if(getObjectSize(h, &size) != MYAPI_SUCCESS) {
// Error handling}這看起來比錯誤處理代碼更好。MYAPIError error;int size;size = getObjectSize(h, &error);if(error != MYAPI_SUCCESS) {
// Error handling}但是，我認為使用返回值返回數據會使代碼更具可讀性。很明顯，在第二個示例中，某些內容被寫入了size變量。您對我為什么應該選擇這些方法或者將它們混合或使用其他方法有任何想法嗎？我不是全局錯誤狀態的粉絲，因為它往往會使庫的多線程使用更加痛苦。編輯：只要他們不涉及異常，C ++關于此的具體想法也會很有趣，因為目前我不能選擇...
3 回答
幕布斯6054654
TA貢獻1876條經驗 獲得超7個贊
我喜歡錯誤作為返回值方式。如果您正在設計api并且想要盡可能輕松地使用您的庫，請考慮以下添加：
將所有可能的錯誤狀態存儲在一個typedef'ed枚舉中，并在lib中使用它。不要只返回整數或更糟，混合整數或不同的枚舉與返回代碼。
提供將錯誤轉換為人類可讀的東西的功能?？梢院芎唵?。只是錯誤枚舉，const char * out。
我知道這個想法使多線程使用有點困難，但如果應用程序員可以設置全局錯誤回調那就太好了。這樣他們就可以在bug追捕會話期間將斷點放入回調中。
希望能幫助到你。
茅侃侃
TA貢獻1842條經驗 獲得超22個贊
我已經使用了這兩種方法，它們對我來說都很好。無論我使用哪一個，我總是嘗試應用這個原則：
如果唯一可能的錯誤是程序員錯誤，請不要返回錯誤代碼，在函數內部使用斷言。
驗證輸入的斷言清楚地傳達了函數所期望的內容，而過多的錯誤檢查會使程序邏輯模糊不清。決定如何處理所有各種錯誤情況可能會使設計復雜化。為什么要弄清楚函數X應該如何處理空指針，如果你可以堅持程序員永遠不會傳遞一個？
白板的微信
TA貢獻1883條經驗 獲得超3個贊
CMU的CERT 有一套很好的幻燈片，建議何時使用每種常見的C（和C ++）錯誤處理技術。最佳幻燈片之一是這個決策樹：
我會親自改變關于這款跑車的兩件事。
首先，我要澄清有時對象應該使用返回值來指示錯誤。如果函數僅從對象中提取數據但不改變對象，則對象本身的完整性不存在風險，并且使用返回值指示錯誤更合適。
其次，在C ++中使用異常并不總是合適的。異常是好的，因為它們可以減少用于錯誤處理的源代碼量，它們通常不會影響函數簽名，并且它們可以非常靈活地傳遞callstack的數據。另一方面，由于以下幾個原因，異常可能不是正確的選擇：
C ++異常具有非常特殊的語義。如果你不想要那些語義，那么C ++異常是一個糟糕的選擇。拋出后必須立即處理異常，并且設計有利于錯誤需要將調用堆棧展開幾個級別。
拋出異常的C ++函數以后不會被包裝成不拋出異常，至少在沒有支付異常的全部代價的情況下也是如此?？梢园祷劐e誤代碼的函數以拋出C ++異常，從而使它們更加靈活。C ++
new通過提供非投擲變體來實現這一目標。C ++異常相對較為昂貴，但這種缺點主要是對于合理使用異常的程序而言過于夸張。程序根本不應該在性能受到關注的代碼路徑上拋出異常。程序報告錯誤和退出的速度并不重要。
有時C ++異常不可用。要么它們在一個人的C ++實現中根本不可用，要么一個代碼指南禁止它們。
由于最初的問題是關于多線程的上下文，我認為本地錯誤指示器技術（在SirDarius的答案中描述的內容）在原始答案中被低估了。它是線程安全的，不會強制錯誤被調用者立即處理，并且可以捆綁描述錯誤的任意數據。缺點是它必須由一個對象保持（或者我想以某種方式與外部相關聯）并且可以說比返回代碼更容易被忽略。
- 3 回答
- 0 關注
- 581 瀏覽
添加回答
舉報
0/150
提交
取消