3 层应用程序的异常捕获最佳实践答案

【问题标题】：Exception Catching Best Practices on 3 Tier Application3 层应用程序的异常捕获最佳实践
【发布时间】：2011-09-09 06:35:56
【问题描述】：

我有一个具有以下 3 层的 WCF：

谁能帮帮我：

上述哪一层是在以下情况下捕获和记录异常的最佳位置：

场景 1：

DLL 发生异常。

场景：2：

BLL 发生异常。

另外，我是否应该总是在 Try and Catch 时包装从 Service 对 BLL 的调用？

【问题讨论】：

【解决方案1】：

这取决于您的系统，但我可能会在 BLL 中记录异常。并且注意你“日志”不要抓住！那就是 - 在接球结束时将重新投掷！

我根本没有在服务中捕获任何内容 - 这只是为了与客户端通信 - 恕我直言，无需在其中放入任何逻辑。

当然：在抛出它们的地方捕获你的预期异常，然后让未异常的通过。

例如：场景 1 - 可能会捕获 SqlExceptions，尝试处理它们，如果没有将它们包装在一些 DAL-Exception 中并抛出这些异常。场景 2 - 可能从第 3 层捕获 DAL 异常，看看您是否可以处理这些或再次包装它们，...

恕我直言，处理、记录和静音各种意外异常 (catch (Exception)) 几乎从来都不是一个好主意 - 此后应用程序状态将非常不确定。

【讨论】：

感谢@Carsten König。 WRAP、LOG 和 HANDLE 有什么区别？
wrap：采用许多不同的异常并将它们放入一个单独的异常中（作为内部异常或替换它们） - 优点：调用您的 BL 的函数不需要知道 DAL 可能抛出的所有异常，只有包装例外。 / 日志：只记录异常并重新抛出 / 处理：捕获异常并进行一些明确定义的清理 - 不要重新抛出或抛出新异常 - 我希望这会有所帮助
嗨@Carsten，您能否澄清您的声明“处理、记录和静音各种意外异常（捕获（异常））几乎不是一个好主意——应用程序状态将非常不确定之后。”
当然——你经常看到像catch(Exception) { } 或catch(Exception) { /* log it */ } 这样的东西，其中每一个 异常都会被捕获并且程序无论如何都会继续运行。但是，如果您考虑这一点，则程序处于未知状态-您不知道发生了什么，也不知道您的数据是否一切正常-因此最好通知用户并让程序死掉-即不是捕获异常或重新抛出它。

【解决方案2】：

阅读 MSDN 上关于 Microsoft Exception Handling Block 的一些文章

它经历了很多场景，并为您提供了一些关于异常处理策略最佳实践的好主意，无论您是否使用异常处理块，如下图所示。

【讨论】：