例外与特殊回报值

编程中哪一个更好？

我不是在谈论完全排他性.对于以下内容更有用:

list.Find,你得到的default(T)或你的价值,而不是ValueNotFound例外(例子).

要么

list.IndexOf,你得到-1或正确的索引.

那么,答案取决于它.

如果在列表中找不到项目,则抛出异常是一种可怕的做法,因为该项目可能不在列表中是完全可行的.

现在,如果这是某种类型的专用列表,并且该项应该绝对可以在列表中找到,那么应该抛出异常,因为您遇到了一种不可行/合理的情况.

一般来说,对于诸如业务规则之类的东西,专门的错误代码更好,因为你意识到这些事情发生的可能性,并且想要对这些可能性作出反应.例外情况适用于您不期望的情况,如果发生则无法继续执行代码.

我已经在某处找到了一个很好的规则,我非常喜欢这个规则.它说 - "当且仅当它不能执行它所要执行的任务时,函数才应该抛出异常".

所以我通常做的是决定一个函数应该做什么(通常来自业务需求或其他东西),然后为其他一切抛出异常.

如果您已经很好地设计了应用程序,那么您的函数将非常小并且执行相对简单的任务并具有简单的返回值.通过上述规则确定例外情况并不困难.

当然,总是存在模糊的情况(比如字典中没有的密钥).那些应该是远在和中间,但在那里你只需要用你的直觉来解决什么是更优雅的解决方案.

哦,所有这一切都永远不会忘记:为了这个工作得好,只能抓住你可以处理的异常.大多数情况下,这意味着您只能在上层UI级别捕获它们,您可以在其中显示,向用户显示它们或记录它们.较低级别可能会finally在对其自身进行一些处理后使用块或重新抛出异常,但低级别的真正捕获异常通常表示设计不良.

经验法则是仅在发生"不应该发生"的事情时才使用例外.

如果您期望对IndexOf()的调用可能找不到有问题的值(合理的期望),那么它应该有一个返回代码(如您所说,可能为-1).永远不会失败的东西,比如分配内存,应该在失败的情况下抛出异常.

另一件需要记住的事情是,在性能方面处理异常是"昂贵的".因此,如果您的代码定期处理异常作为正常操作的一部分,则它将无法以尽可能快的速度执行.