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