我一直觉得期待例外定期抛出，并用它们作为流动逻辑是一件坏事。例外觉得自己应该是​​，好了，的异常的。如果您期望和规划一个例外，这似乎表明您code应该重构，至少在.NET ... 然而。最近的一个场景让我停下来。我在不久前发布的这个在MSDN上，但我想，以产生有关它的详细讨论，这是一个完美的地方！ 所以，说你有一个数据库表，它有一个外键，其他几个表（在最初促使辩论中，有4外键指向它的情况下）。要允许用户删除，但只如果没有外键引用;你不想级联删除。 我通常只是做一个检查，看看是否有任何引用，如果有，我告知做删除的用户来代替。这很容易和轻松的写在LINQ的相关表是对象的成员，因此，Section.Projects和Section.Categories和等等是好的，有智能感知和所有的输入... 但事实是，LINQ，然后有可能全部命中4个表，看看是否有任何结果行指向该记录，并进入数据库，显然永远是相对昂贵的操作。 在这个项目的领导叫我改变它只是赶上与547（外键约束）一个code进行了SQLException并处理它的方式。 我是... 耐的。 但在这种情况下，它可能是一个很多更有效地吞下异常有关的开销比吞下4表命中...特别是因为我们要做的在任何情况下的检查，但我们做足了异常的情况下当没有孩子...... 加上数据库确实应该是一个负责处理参照完整性，这是它的工作，它确实很好...... 所以他们赢了，我改变了它。 在一定程度上它仍然感觉的错误的我虽然。 你们有什么想期待和故意处理异常？是不是好当它看起来会比事先检查更有效？是不是更混乱下开发看着你的code，或更少混淆？它是安全的，因为数据库可以了解新的外键约束，开发商可能不会想到要增加一个检查？或者是它的视角对究竟你认为最好的做法是？

I always felt that expecting exceptions to be thrown on a regular basis and using them as flow logic was a bad thing. Exceptions feel like they should be, well, the "exception". If you're expecting and planning for an exception, that would seem to indicate that your code should be refactored, at least in .NET... However. A recent scenario gave me pause. I posted this on msdn a while ago, but I'd like to generate more discussion about it and this is the perfect place! So, say you've got a database table which has a foreign key for several other tables (in the case that originally prompted the debate, there were 4 foreign keys pointing to it). You want to allow the user to delete, but only if there are NO foreign key references; you DON'T want to cascade delete. I normally just do a check to see if there are any references, and if there are, I inform the user instead of doing the delete. It's very easy and relaxing to write that in LINQ as related tables are members on the object, so Section.Projects and Section.Categories and et cetera is nice to type with intellisense and all... But the fact is that LINQ then has to hit potentially all 4 tables to see if there are any result rows pointing to that record, and hitting the database is obviously always a relatively expensive operation. The lead on this project asked me to change it to just catch a SqlException with a code of 547 (foreign key constraint) and deal with it that way. I was... resistant. But in this case, it's probably a lot more efficient to swallow the exception-related overhead than to swallow the 4 table hits... Especially since we have to do the check in every case, but we're spared the exception in the case when there are no children... Plus the database really should be the one responsible for handling referential integrity, that's its job and it does it well... So they won and I changed it. On some level it still feels wrong to me though. What do you guys think about expecting and intentionally handling exceptions? Is it okay when it looks like it'll be more efficient than checking beforehand? Is it more confusing to the next developer looking at your code, or less confusing? Is it safer, since the database might know about new foreign key constraints that the developer might not think to add a check for? Or is it a matter of perspective on what exactly you think best practice is?

推荐答案

哇，

首先，你能请下来提炼出的问题了一下，而这是很好的阅读深思熟虑和解释的问题，这是相当多的消化。

First off, can you please distill the question down a bit, while it was nice to read a well thought out and explained question, that was quite a lot to digest.

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

The short answer is "yes", but it can depend.

我们有一些应用，我们有许多捆绑在SQL查询的业务逻辑（不是我设计的政府网站！）。如果这是它的结构，管理是难以说服的，否则，因为它已经工程。 在这种情况下，它真正使一个大问题？由于它仍然横跨电线回一趟。服务器是否做很多它意识到之前，它不能继续（ieif存在着发生到你的行动事务的序列，它再通过倒下了一半，浪费时间？）。 是否有意义做在UI第一检查？这是否与您的应用程序帮助吗？如果它提供了更好的用户体验？ （即我所看到的，你通过几个步骤向导步骤的情况下，它开始，然后倒了，当它有一切必要的步骤1后摔倒在信息）。 是并发的问题？难道记录可能会被删除/编辑或任何在你提交发生（如经典的 File.Exists 嘘，嘘）。 We have some applications where we have lots of business logic tied up in the SQL queries (not my design Gov!). If this is how it is structured, management can be difficult to convince of otherwise since it "already works". In this situation, does it really make a big deal? Since it's still one trip across the wire and back. Does the server do much before it realises that it cannot continue (i.e.if there is a sequence of transactions that take place to your action, does it then fall over half way through, wasting time?). Does it make sense to do the check in the UI first? Does it help with your application? If it provides a nicer user experience? (i.e. I have seen cases where you step through several steps in a wizard, it starts, then falls over, when it had all the info it needed to fall over after step 1). Is concurrency an issue? Is it possible that the record may be removed/edited or whatever before your commit takes place (as in the classic File.Exists boo-boo).

在我看来：

我会做的两个的。如果我能快速失败，并提供更好的用户体验，伟大的。任何预期的SQL（或任何其他）例外，应被逮住并反馈适当反正。

I would do both. If I can fail fast and provide a better user experience, great. Any expected SQL (or any other) exceptions should be getting caught and fed back appropriately anyway.

我知道有某些例外情况下不应该使用比的特殊情况下的其他一个concensus，但请记住，我们正在跨越应用程序边界这里，不指望什么。就像我说的，这就像 File.Exists ，没有点，它可以反正你访问它之前被删除。

I know there is a concensus that exceptions should not be used for other than exceptional circumstances, but remember, we are crossing application boundaries here, expect nothing. Like I said, this is like the File.Exists, there is no point, it can be deleted before you access it anyway.