醒目的例外情况作为预期的程序执行流动的控制？

Question

我总觉得期待的例外情况被抛弃在定期的基础上，并利用他们作为流动的逻辑是一件坏事。例外情况感觉他们应该是，好了，"异常".如果你期待和规划为一种例外，这似乎表明，你的代码应该进行了重构，至少在。净...
然而。最近的一个方案给了我暂停。我布这个msdn上前一段时间，但我想产生更多的讨论，这是一个完美的地方！

所以说你已经有了一个数据库表，其中有一个外国的关键几个其他表格中的(在这种情况，即最初促使辩论中，有4个外键指向的)。你想让用户可以删除，但只有如果没有外国的关键参考资料；你不想联级删除。
我通常只是做个检查来看看是否有任何引用，如果有，我告知用户而不是做删除。很容易轻松写意在皇宫作为相关表格上的成员对象，因此部分。项目和部分。类别和等是很好的类型智能感知和所有的...
但事实上是皇宫然后到打击的潜在所有4个表格，看看是否有任何结果的行指认的记录，并击中据库显然是始终是一个相对较昂贵的运作。

这导致在这个项目让我改变它只是抓住一个SqlException码的547(外键约束)，并处理它的方式。

我是...
耐.

但在这种情况下，它可能是一个更多有效吞下的例外相关的开销比吞下表4命...特别是因为我们要做检查，在每种情况下，但我们不遗余力的例外的情况下，当有没有孩子...
再加上数据库真的应该是一个负责处理引用完整性，这是它的工作和它确实很好...
所以他们赢了，我改变它。

在某种程度上它仍然感觉 错误的 我虽然。

你们怎么认为关于预期和有意处理异常?它是好的时，它看起来像它将可以更有效的事先检查?这是更加令人困惑的下一个开发商看你的码，或减少混乱?它是安全的，因为该数据库可能知道有关新的外国主要制约，开发商可能不会觉得添加一个检查吗？或者它是一个角度的问题上究竟是什么你认为的最佳做法是什么？

Answer 1

哇，

第一关，你可以请你提取问题的下一位，同时它是很好的阅读一个经过深思熟虑，并解释问题，这是相当多的摘要。

简短的回答是"是的"，但是它可以依赖的。

• 我们有一些应用中，我们有很多的业务逻辑绑在SQL queries(不是我的设计Gov!).如果这是它的结构、管理可能很难说服的，否则，因为它"已经工作"。
• 在这种情况下，它不会真正使大不了的？因为它仍然是一个旅行跨线和回。不会的服务器做到之前意识到，它不能继续(i。e.如果有一个序列的交易，采取地方行动，它不会再下降超过一半的方式通过，浪费时间?).
• 它是有意义的做检查UI中第一?它不会帮助你的应用程序？如果它提供了一个更好的用户经验？(即我已经看到情况的步骤，通过几个步骤中一个向导，它开始，然后落过，当它的所有信息，就需要落在后步骤1)。
• 是并发的一个问题吗？是否有可能记录可以删除/编辑或什么的之前，你的承诺需要的地方(作为经典 File.Exists 嘘，嘘).

在我的意见：

我会做的 既.如果我能快速失败并提供更好的用户经验，伟大的。任何预期SQL(或任何其他)的例外情况应当被抓获并送回适当的。

我知道有一个共识，例外不应用于其他比 特殊情况, 但是记住，我们正越过应用界线在这里， 指望什么.就像我说,这是喜欢的 File.Exists, 没有一点，它可以删除之前，你的访问。

Answer 2

你的领导是绝对正确的。例外不仅适用于蓝月情况下的一次，而且特别适用于除预期结果之外的报告。

在这种情况下，仍会进行外键检查，例外是通知您的机制。

你不应该做的是用一条毯子捕获语句来捕捉和抑制异常。进行细粒度的异常处理特别是为什么首先设计了异常。

Answer 3

我认为你是对的，异常应该只用于处理意外的结果，在这里你使用异常来处理可能预期的结果，你应该明确处理这个案例但仍然抓住显示可能错误的例外。

除非这是整个代码处理此案例的方式，否则我会支持你。只有在实际出现问题时才应该提出性能问题，即它将取决于这些表的大小和使用该函数的次数。

Answer 4

好问题。但是，我找到答案......可怕！
一个例外是一种GOTO。
我不喜欢以这种方式使用异常，因为这会导致意大利面条代码。
就那么简单。

Answer 5

你在做什么并没有错。例外并非毫无疑问的“例外”。它们的存在是为了允许调用对象根据需要进行细粒度的错误处理。

Answer 6

捕获特定的SqlException是正确的做法。这是SQL Server传递外键条件的机制。即使您可能喜欢异常机制的不同用法，这也是SQL Server的用法。

此外，在检查四个表时，其他一些用户可能会在检查完成之前但在您阅读该表之后添加相关记录。

Answer 7

我建议你叫一个存储程序，检查是否有任何的依赖，然后删除如果没有任何.这样一来，检查完整性。

当然，你可能会想要一个不同的储存程序单中删除与批删除...批删除可能看起来为儿童的行和返回设置的记录，没有资格获得批量删除(有儿童行)。

Answer 8

我不喜欢在程序中到处看到异常，但在这种情况下我会使用异常机制。

即使您在LINQ中进行测试，也必须捕获异常，以防有人在使用LINQ测试完整性时插入子记录。既然你必须检查异常，为什么要复制代码？

另一点是这种“短程”。异常不会导致维护问题，也不会使您的程序更难以阅读。您将拥有try，要删除的SQL调用，以及10行代码中的所有内容。意图很明显。

不喜欢抛出一个异常，这个异常将被捕获到堆栈中的5个过程调用上面，并且确保其间的所有对象都已正确处理（释放）。

异常并不总是一个神奇的答案，但在这种情况下使用它们我觉得不对。

我的两分钱，

伊夫