2012-01-28 54 views
3

我有一個類可以對給定對象執行多種類型的轉換。替代返回對象的方法的例外

所有數據都是由用戶提供的(通過手工製作的命令文件),但大多數情況下,無法確定文件命令是否有效,直到我們開始轉換它(如果我們先檢查了所有內容,我們會結束up做與轉換本身相同的工作量)

這些轉換方法在對象上調用,它返回一個新轉換的對象,但是如果出現問題,我們會拋出異常,因爲返回一個對象(即使是空白對象)可能會與成功混淆,而異常會發出明確的信號,表示存在問題,並且無法返回對象。這也意味着,我們不需要所謂的「查看最近的錯誤」類型的函數來找出到底哪裏出了問題(錯誤代碼,消息,報表等)

但是從如此看來這個閱讀無數的答案是不正確的,因爲無效的用戶輸入不是一個特殊的情況,並且由於這種事情的複雜性,用戶提交不正確的命令文件並不罕見。

性能是不是一個真正的問題在這裏,因爲如果我們打一個錯誤,我們必須停止並返回給用戶。

如果我使用的返回碼我不得不把輸出對象作爲參數,然後檢查我需要很長的嵌套,如果返回代碼塊(即你從COM檢查HRESULT的方式)

如何在避免這種情況下的異常的同時保持代碼合理整齊?

+0

你能不能添加一個標誌,告訴我們,如果該實例是否有效? – 2012-01-28 14:29:28

+0

¤主要答案是不要進行設計更改以適應愚蠢的理想。切實可行,記住羅納德里根的話:如果它沒有壞掉,不要修理它。也就是說,你可以使用Barton Nackman的「Fallible」概念,一個返回對象類型,它可以在邏輯上是空的,並且如果包含的值是空的,則訪問其失敗。失敗可能是終止或例外。 'boost :: optional'類基於非法結果訪問的異常。乾杯&hth。, – 2012-01-28 14:29:41

+0

@puller:感謝您的評論,但我仍然需要在某處檢查該標誌(如果我要檢查標誌,我不想繼續處理該標誌設置)我也可以檢查返回值。 – TownCube 2012-01-28 14:30:56

回答

3

你的問題的設計確實使其本身例外。一旦用戶輸入錯誤的輸入文件,程序執行將暫停或無效的事實是「特殊情況」的標誌。當然,很多程序運行將以拋出異常(並被捕獲)結束,但這只是程序的一次執行。

您正在閱讀的有關異常在其他情況下使用時速度緩慢的事情只有在程序可以恢復並且必須經常恢復時纔有效(例如,編譯器無法在搜索目錄中找到標題,必須查看搜索目錄列表中的下一個目錄,這真的發生了很多)。

使用異常。如有疑問,請評估這是否會造成性能下降。清潔代碼>>遵循人們對SO的評論。但是,再一次,這將是我忽略我剛纔所說的理由。

1

好了,我不會(避免例外)。如果你確實需要一個「錯誤報告」機制(並且你這樣做),除了返回值和異常之外沒有太多東西。我認爲關於什麼是非常特殊的(並且因此值得例外的)和什麼不是特別的,對於阻止你解決你的問題並不重要。特別是如果表演不是問題。但是如果你真的想避免異常,你可以使用某種全局隊列排列你的錯誤iformation。但是,如果你問我,那是非常醜陋的。在對象本身