我正在寻找单元测试或OOP原则方面的"特殊"定义.在谈到异常抛掷时,有几次SO,我看到过这样的评论,"好吧,我不会考虑让Bar从Foo变得特别." (有一个trollface图释？)
我做了一些谷歌搜索,并没有立即回答.是否有任何比观点或偏好更客观的定义,经验法则或指导方针？如果一个人说"这是例外"而另一个人说"不,不是",那么如何解决这一争议呢？
编辑:哇,所以已经有很多答案,评论不同意,而且他们似乎都是回答者的意见:P没有人引用维基百科页面或文章来自灰熊的片段.在"元回答"我是从这个考虑是有是没有商定何时使用异常的经验法则.在选择抛出异常时,我更自信地运用自己的,个人的,特殊的规则.
我不同意其他关于需要"特殊"的事情的答案,以保证"例外".我说"异常"是指你想要通过投掷向上传播的物体来打破正常的控制流程.
例外是一种语言功能.他们是达到目的的手段.它们并不神奇.与任何其他功能一样,当您使用它们时,应该在您需要它们提供的内容时引导,而不是通过它们的名称来引导.
这是特殊的,如果:
这是一个失败的条件. 和
它不经常发生.和
报告它没有更好的机制.
编辑
从Dan Weinreb的博客文章中偷偷偷窃,Ken在这里发布,我想提供以下有关例外情况的摘要.
方法的契约定义了如何(以及是否)发出异常条件(即失败)的信号.如果方法说某事是例外,那就是.当然,这留下了我们应该如何设计合同的问题.
例外情况的好处是不需要呼叫者进行任何检查,也可以自然冒泡,直到被能够处理它们的东西捕获为止.它们还可以包含重要的细节,用户可读的文本和堆栈跟踪.这些功能使它们成为阻止进一步处理但不可预测或不常见的故障情况的理想选择,或者显式错误处理会破坏代码流的情况.它们特别适用于"永远不会发生"但实际上具有灾难性的错误(例如堆栈溢出).
标志,错误代码,魔术值(NULL,nil,INVALID_HANDLE等)和其他基于回归的机制不会占用流量,因此更适合于本地常见和最佳处理的情况,特别是那些可能出现故障的情况解决了.由于它们按惯例操作而不是命令,因此除非可以设计无效值以在实际使用时引起异常(例如用于读取的INVALID_HANDLE),否则不能指望它们被检测和处理.
在强健代码中使用异常时,每个方法都应捕获意外异常并将它们包含在合同中的异常中.换句话说,如果你的方法不承诺抛出NullReferenceException,你需要捕获它并在更通用或特定的东西中重新抛出它.他们被称为例外,而不是惊喜!