我总是觉得期望定期抛出异常并将它们用作流逻辑是一件坏事.例外情况应该是,他们应该是" 例外 ".如果你期望并计划一个异常,这似乎表明你的代码应该被重构,至少在.NET中......
但是.最近的一个场景让我停下来.我刚刚在msdn上发布了这个,但是我想对它进行更多的讨论,这是一个完美的地方!
所以,假设你有一个数据库表,其中有几个其他表的外键(在最初提示辩论的情况下,有4个外键指向它).您希望允许用户删除,但仅限于没有外键引用; 你不想级联删除.
我通常只是检查是否有任何引用,如果有,我通知用户而不是删除.在LINQ中编写它是非常容易和轻松的,因为相关表是对象的成员,所以Section.Projects和Section.Categories等等很好用intellisense和所有类型...
但事实是LINQ然后必须潜在地检查所有4个表以查看是否有任何结果行指向该记录,并且命中数据库显然总是相对昂贵的操作.
这个项目的负责人让我把它改成只捕获一个代码为547(外键约束)的SqlException并以这种方式处理它.
我......
抗拒.
但是在这种情况下,吞下与异常相关的开销可能比吞下4个表命中更有效...特别是因为我们必须在每种情况下进行检查,但我们在这种情况下没有例外当没有孩子的时候......
加上数据库真的应该是负责处理参照完整性的人,这是它的工作而且做得很好......
所以他们赢了,我改变了它.
在某种程度上,我觉得我觉得不对.
你们对期望和故意处理异常有什么看法？它看起来比预先检查更有效吗？对于下一个查看代码的开发人员来说,更令人困惑的是它更令人困惑吗？它是否更安全,因为数据库可能知道开发人员可能不会考虑添加检查的新外键约束？或者是关于你认为最佳实践究竟是什么的观点？
你的领导是绝对正确的.例外不仅适用于蓝月情况下的一次,而且特别适用于除预期结果之外的报告.
在这种情况下,仍会进行外键检查,例外是可以通知您的机制.
你不应该做的是通过毯子捕获声明来捕获和抑制异常.进行细粒度异常处理特别是为什么首先设计异常.
京公网安备 11010802040832号 | 京ICP备19059560号-6 