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时，他们会失败。

速度是不是真正的问题的。但只是一般的“这是因为这个原因更好”就足够了。

在绝大多数情况下，返回nullptr是错误的。添加一个HasValue（）方法，以便客户端代码可以发现该值不存在。如果用法指示该值始终存在，则不要执行任何操作，以便客户端程序员可以轻松修复其错误。 – 2011-02-09 12:14:05

答

我坚信，如果您有合理的法律条件允许，您不应该发现异常来检测它。换句话说，使用if语句。这类似于让阵列上的所有循环用完，直到你得到一个ArrayIndexOfBoundsException并且尝试......将它陷入遗忘之中。

在一个相关的说明，它可能是有意义的投掷KeyNotFoundException而不是返回null。呼叫者可能会采取这种方式null并尝试解除引用它，这会转移焦点并使其更难找到该错误。

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

答

给你所描述的情况，我认为这只取决于你的喜好。无论如何，当失败的条件是确定性的，并且你可以预见它时，它总是一个更好的解决方案，不要使用try..catch块，并且只对非确定性和不可预知的错误留下它。

反对异常而不是“if”块的所有参数都只是关于性能（速度，内存，堆栈，ecc ...）并且是学术性的。实际上，当你需要一个完全无异常的方法，并且不关心返回空值的原因时，只需把你的5行try..catch块，并忘记它！ ;）

C++/CLI良好的编码习惯，索引属性if-check或try..catch？

相关推荐