我总觉得期望定期抛出异常并将其用作流程逻辑是一件坏事。例外感觉就像它们应该是“例外“。如果您期待并计划出现异常，这似乎表明您的代码应该重构，至少在 .NET 中......
然而。最近的一个场景让我停了下来。我不久前在 msdn 上发布了此内容，但我想引发更多关于它的讨论，这是一个完美的地方！
因此，假设您有一个数据库表，其中有几个其他表的外键（在最初引发争论的情况下，有 4 个外键指向它）。您希望允许用户删除，但前提是没有外键引用；你不想级联删除。
我通常只是检查是否有任何引用，如果有，我会通知用户而不是删除。在 LINQ 中编写这一点非常容易和轻松，因为相关表是对象的成员，因此使用智能感知和所有内容键入Section.Projects和Section.Categories等等非常好......
但事实是，LINQ 然后必须访问所有 4 个表，以查看是否有任何结果行指向该记录，并且访问数据库显然始终是一个相对昂贵的操作。
该项目的负责人要求我将其更改为仅捕获代码为 547（外键约束）的 SqlException 并以这种方式处理它。
我曾是...
抵抗的.
但在这种情况下，吞下与异常相关的开销可能比吞下 4 个表命中要高效得多...特别是因为我们必须在每种情况下都进行检查，但在这种情况下我们可以避免异常当没有孩子的时候...
另外，数据库确实应该负责处理引用完整性，这是它的工作，而且它做得很好......
所以他们赢了，我改变了它。
某种程度上还是感觉wrong但对我来说。
你们对于期待和有意处理异常有什么看法？看起来比事先检查更有效率，这样可以吗？对于下一个查看您的代码的开发人员来说，它是更令人困惑，还是不那么令人困惑？是否更安全，因为数据库可能知道开发人员可能不会考虑添加检查的新外键约束？还是您对最佳实践的看法到底是什么？
你的领导是绝对正确的。例外情况不仅仅是千载难逢的情况，而且特别是在报告非预期结果时。
在这种情况下，外键检查仍然会发生，并且异常是可以通知您的机制。
你不应该做的是使用一揽子声明来捕获和抑制异常。进行细粒度的异常处理正是最初设计异常的具体原因。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
