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 语句带有 try..catch 块？
在这两种情况下，当它们失败时返回 nullptr
并不是真正的问题。
A rather short and simple question.
Let's use this piece of code:
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 ^>();
}
};
Would it be better to surround/pre-check the return with an if statement ( if( aDictionary->ContainsKey(index) ) or would it be better to surround the return statement with a try..catch block?
In both cases returning nullptr when they fail.
Speed is not really of the issue. But just a general "this is better for that reason" would suffice.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我坚信，如果存在您合理允许的法律条件，您不应该捕获异常来检测它。换句话说，使用
if语句。这类似于让数组上的所有循环都运行完，直到获得 ArrayIndexOfBoundsException 并尝试...将其捕获。与此相关的是，该属性抛出
KeyNotFoundException而不是返回null可能是有意义的。调用者可能会获取此null并尝试取消引用它，这会转移焦点并使查找错误变得更加困难。I firmly believe that if there is a legal condition that you reasonably allow, you should not catch an exception to detect it. In other words, use an
ifstatement. This is akin to letting all loops on arrays run out until you get anArrayIndexOfBoundsExceptionand try...catch it into oblivion.On a related note, it might make sense for the property to throw a
KeyNotFoundExceptioninstead o returningnull. Callers might take thisnulland try to dereference it, which shifts the focus and makes it harder to find the bug.鉴于你所描述的情况，我认为这仅取决于你的喜好。
无论如何，当失败条件是确定性的并且您可以预见它时，不使用 try..catch 块始终是更好的解决方案，而只将其保留用于非确定性和不可预测的错误。
所有反对异常而不是“if”块的争论都只是关于性能（速度、内存、堆栈、ecc...）并且是学术性的。实际上，当您需要一个完全无异常的方法，并且不关心空返回值的原因时，只需将您的 5 行 try..catch 块放在其中，然后就可以忘记它了！ ;)
Givent the circumstances described by you, I think it depends only on your preferences.
Anyway, when the failing condition is deterministic, and you can anticipate it, it's always a better solution not use the try..catch block, and leave it only for non-deterministinc and unpredictable errors.
All arguments against exceptions instead of "if" blocks, are only about performances (speed, memory, stack, ecc...) and are accademic. In real word, when you need a totally exception-free method, and don't care about reasons of null return values, just put your 5 lines try..catch block, and forget it! ;)