.net – 捕获异常作为预期的程序执行流控制？

所以说,你有一个数据库表,其中有几个其他表的外键(在最初引起辩论的情况下,有4个外键指向它).你想允许用户删除,但只有没有外键引用;你不想级联删除.
我通常只是检查一下是否有任何引用,如果有的话,我通知用户而不是删除.在LINQ中写入相关表格是对象上的成员非常容易和轻松,因此Section.Projects和Section.Categories等是很好的键入智能感知和所有…
但事实是,LINQ然后必须击中潜在的所有4个表,以查看是否有任何结果行指向该记录,并且击中数据库显然总是相对昂贵的操作.

这个项目的领导要我改变它,只是用547(外键约束)的代码捕获一个SqlException,并以这种方式处理它.

我曾是…
耐药.

但是在这种情况下,吞咽异常相关的开销可能要比吞噬4个表格命中更有效…特别是因为我们必须在每一种情况下进行检查,但是我们在这种情况下免除了异常当没有孩子的时候
加上数据库真的应该是负责处理参照诚信的人,这是它的工作,它做得很好…
所以他们赢了,我改变了.

在某种程度上,我仍然觉得我错了.

你们有什么想法和故意处理例外？看起来像预先检查会更有效吗？下一个开发人员看你的代码更混乱,还是更混乱吗？是否更安全,因为数据库可能会知道开发人员可能没有想到添加检查的新外键限制？或者这是一个关于你认为最佳实践是什么的观点的问题？

解决方法

首先,你可以请一点点解释这个问题,而很好阅读一个深思熟虑的解释问题,这是相当多的消化.

简短的答案是“是”,但它可以依赖.

>我们有一些应用程序,我们有很多业务逻辑绑定在SQL查询(而不是我的设计Gov！).如果这是结构化的,管理层可能很难说服其他方式,因为它“已经有效”.
>在这种情况下,真的有很大的作用吗？因为它仍然是一个穿过电线和背部的旅程.服务器在实现它不能继续之前做得很好(即,如果有一系列的事务发生在你的行动中,它是否会超过一半,浪费时间？).
>首先在用户界面中进行检查是否有意义？它有助于您的应用程序吗？如果它提供更好的用户体验？ (也就是说,我看到一些情况,你们在一个向导中通过几个步骤,它开始,然后掉下来,当它有所有的信息需要在第1步之后).
>并发是一个问题吗？可能会在您的提交发生之前删除/编辑记录或任何内容(如经典的File.Exists boo-boo).

我的想法是：

我会做两个如果我能快速失败并提供更好的用户体验,那么很棒.任何预期的SQL(或任何其他)异常应该被捕获并反馈回来.

我知道有一个共识,除了特殊情况外,不应该使用异常,但请记住,我们在这里跨越应用程序界限,什么都不期望.就像我说的,这就像File.Exists,没有任何意义,它可以在你访问之前被删除.

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!