DAL层异常处理

[fm119]

当异常发生在DAL层中，应该由DAL层自己处理还是交由上层处理。

如何是交由上层处理，那 根据DAL不同的实现，上层的catch 也要不同，那是否代表上层依赖下层?

[以专业开发人员为伍]

有的人说“程序访问关系数据库系统，如果数据库抛出异常，我就要try...catch然后返回一个负数整数来代表异常”，这就是很扯淡的。 30年前的低级的c语言程序，因为底层异常就会造成进程崩溃，所以才用返回整数来表示是否有异常。而现在你的应用框架底层机制都已经有着复杂的“异常框架”了，你还用什么返回值来表示抛出了异常？ 那可以肯定是一些人最初只会一点c语言，只看过一点c语言编程的书，然后跑到.net、java之类的平台来坑人，才会这样告诉你这样来编程的。 异常本身就会自动向上抛出，这是.net 框架设计好的机制。如果你不知道该如何“自己处理”就不要奢谈什么“DAL层自己处理”，这其实是废话。但是放到有些人那里，不知道该如何处理，却偏要写个无聊的 try....catch 代码，然后甚至在 catch 代码中再 trrow，那种多余的代码是除了让 vs 调试器无法在准确位置开始调试，还能有什么用？

[正怒月神]

我都是在Global的Application_Error处理

[以专业开发人员为伍]

“当异常发生在DAL层中”这个时候该由哪一层处理异常，根本无从谈起。 如果空洞地说什么“处理异常”这种话，还不就是那种try...catch然后在 catch 中再来一个 throw 这种东西嘛？这除了让 vs 调试器丧失调试能力，还能有什么用？ 放大到软件开发组织的基本道理的角度，产品设计中明文规定捕获异常也不是随便在 Debug 中进行的，它是在 Release 版本中的特性。在 Debug 版本中，就是要让异常尽早抛出来，让 vs 调试器立刻进入调试状态。能为 Debug 和 Release 进行条件编译， 这是起码的要求。你不会在 Debug 版本中也去按照 Release 的规则去编程吧？

[以专业开发人员为伍]

如果你的代码调用了 DAL 层代码，结果它根本 hold 不住异常，那么你自然就不得不在 DAL 层处理异常，以免表现层系统崩溃。 反之，如果你在一个比较成熟的系统上，这个异常会“正常地”抛出，你就要看看最后这个异常抛出到哪里。而你的产品设计人员当初在文档中告诉你如何对异常进行表现，那么你就应该用尽量直截了当的方式在合适的机制下去捕获异常。你在底层的某个技术阶段去想当然地 try...catch，这完全是多余的，这是用技术来代替现实。如果脱离了现实，技术算个屁啊。

[堆代码的爱因斯坦]

sp1234你说了了一大堆，我没看懂你到底要表达什么

[娃都会打酱油了]

不管任何，交上层，如果某些地方拦截了，会导致一旦出异常，排查会很困难

[以专业开发人员为伍]

你的业务逻辑层既然是直接调用 DAL 的，那么自然是依赖于你调用的东西。业务逻辑层的一个主要功能就是用来隔离 DAL 的。 至于处理异常，不一定要写 try...catch。你试试看你的表现层能不能捕获异常？

[xdashewan]

我个人是这么看这个问题的，异常你得分开来看，一种是可预见异常，简单的例子就是除0啊强转啊导致的，这里异常不但不应该抛出反而应该在逻辑层就被排除掉。另一种是不可预见的异常，比如数据库连接在执行时突然断了，这类异常完全和逻辑无关，所以放逻辑层处理显然不合适，必须记录日志，可能的话要通知相关人员。

[wanghui0380]

额，什么叫dal不同catch也不同，没有任何不同，对于异常我们只分业务逻辑异常（不符合业务规则的异常）和执行异常（系统自己的异常，比如什么conn出错，某某dll缺少依赖） 业务规则异常自己继承实现一个mylogic异常类就行，无论你是什么dal，你对业务部分异常都抛这个就成 执行异常通常不用管直接写入log4net中，以便维护人员排查错误 所以你这么一看，就知道了，他不会出现什么catch的不同

[fm119]

引用 1 楼 sp1234 的回复:

你的业务逻辑层既然是直接调用 DAL 的，那么自然是依赖于你调用的东西。业务逻辑层的一个主要功能就是用来隔离 DAL 的。 至于处理异常，不一定要写 try...catch。你试试看你的表现层能不能捕获异常？

你是说异常抛出到表现层才处理? 另外，不一定要写try...catch 是指 使用返回值判断错误?

[以专业开发人员为伍]

引用 4 楼 fm119 的回复:

你是说异常抛出到表现层才处理? 另外，不一定要写try...catch 是指 使用返回值判断错误?

一个成熟的系统自己就有多种异常机制。 你所谓的“异常处理”是什么意思，难道你是先说“我要处理”然后才考虑处理吗？设计软件时都是先从产品设计的角度把异常时的表现设计出来，然后才考虑如何编程的。只有那些盲目乱背书本的人才会说“我就是想处理，但是怎么处理我不知道”的这种盲目地非要求别人给自己什么代码供自己抄袭。 当你说不出如何让表现的异常的时候，不要去奢谈什么异常、不要去奢谈什么 try....catch。我只是让你去看看你自己的表现层会得到什么样的异常，我并没有说你的程序该如何编程。因为我认为你还远远没有到这个程度，你还在纠结编程技术，而不是从真正的软件最终的需求出发。就算是你在DAL写上三层try...catch，那么你的表现层如何知道数据操作有异常、如何获得InnerException的具体错误解释和调试信息？你不是还得回答这个问题嘛。所以我让你先把精力放到该考虑的高层次的设计问题上，先不要从底层去拼凑。 与此类似地，我也从来没有说过什么“使用返回值判断错误”。那都是i因为你不去花精力去测试你的表现层如何捕获业务逻辑层抛出的异常，然后就从底层来胡乱偷换我的意思。我认为你根本没有去看看你的程序的表现层在异常时做了什么。 先自己贴出你的表现层在异常时的表现，先不要过度纠结底层。

[以专业开发人员为伍]

拿一个比较古老的 asp.net 来说，它在页面级有 Page_Error 方面的事件可以处理异常，在应用程序级别 Global.asax 中可以定义 Application_Error 方面的事件可以处理异常，也可以在网站配置中统一为各种 http 异常问题（例如5xx、4xx类型问题）配置异常处理页面，等等地它有多种在不同地方统一地处理异常的机制。但是如果你一个机制也不理解，就是死抠底层是否应该try....catch，然后又不知道该如何设计异常处理，这不就是自相矛盾嘛。 比如说你在一个单位里上班，如果你发现了系统性的风险，你应该报告给主管人员。现在你说你要自己“处理异常”，然后又问人家“我该如何处理异常，请给我一个永远正确永远万能的例子给我抄一下”，这不就是多余地嘛。原来的自动化机制本身就是交由上级来处理这类问题的，不让你自己想当然地。现在你纠结你想隐瞒异常然后额外再“使用返回值判断错误”给领导，这不是画蛇添足地“处理”嘛。