C++/CLI良好的編碼習慣，索引屬性if-check或try..catch？

一個相當簡短的問題。C++/CLI良好的編碼習慣，索引屬性if-check或try..catch？

讓我們使用這段代碼：

public ref class Foo 
{ 
private: 
    System::Collections::Generic::Dictionary<System::String ^,System::String ^>^aDictionary; 

public: 

    property System::String^SomeIndexedProperty[System::String ^] 
    { 
    public: System::String^get(System::String^index) 
      { 
       return aDictionary[index]; 
      } 
    } 

public: 
    Foo(void) 
    { 
     aDictionary = gcnew System::Collections::Generic::Dictionary<System::String ^,System::String ^>(); 
    } 
};

它會更好包圍/前檢查與if語句（if(aDictionary->ContainsKey(index))退貨或者倒不如包圍return語句用一試。 .catch塊？

在這兩種情況下返回nullptr時，他們會失敗。

速度是不是真正的問題的。但只是一般的「這是因爲這個原因更好」就足夠了。

來源

2011-02-09 Daan Timmer

在絕大多數情況下，返回nullptr是錯誤的。添加一個HasValue（）方法，以便客戶端代碼可以發現該值不存在。如果用法指示該值始終存在，則不要執行任何操作，以便客戶端程序員可以輕鬆修復其錯誤。 – 2011-02-09 12:14:05

我堅信，如果您有合理的法律條件允許，您不應該發現異常來檢測它。換句話說，使用if語句。這類似於讓陣列上的所有循環用完，直到你得到一個ArrayIndexOfBoundsException並且嘗試......將它陷入遺忘之中。

在一個相關的說明，它可能是有意義的投擲KeyNotFoundException而不是返回null。呼叫者可能會採取這種方式null並嘗試解除引用它，這會轉移焦點並使其更難找到該錯誤。

來源

2011-02-09 11:19:58

我同意，例外情況是例外情況，而不是例行故障。 – Massif 2011-02-09 11:28:46

給你所描述的情況，我認爲這隻取決於你的喜好。無論如何，當失敗的條件是確定性的，並且你可以預見它時，它總是一個更好的解決方案，不要使用try..catch塊，並且只對非確定性和不可預知的錯誤留下它。

反對異常而不是「if」塊的所有參數都只是關於性能（速度，內存，堆棧，ecc ...）並且是學術性的。實際上，當你需要一個完全無異常的方法，並且不關心返回空值的原因時，只需把你的5行try..catch塊，並忘記它！ ;）

來源

2011-02-09 11:24:22 BertuPG

C++/CLI良好的編碼習慣，索引屬性if-check或try..catch？

回答

相關問題