分层架构中的异常处理答案

【问题标题】：Exception handling in layered architecture分层架构中的异常处理
【发布时间】：2011-04-25 03:56:03
【问题描述】：

我们正在以分层设计重构（当然也包括重新设计）我们的服务。我们有服务运营层（BLL）、网络抽象层->（处理网络代理）、数据抽象层。但是我们对我们的异常处理策略有点困惑。

我们不想将过多的 BLL 信息暴露给外界。（从其他层到bll都可以）
我们不想用 try catch 堆栈弄乱代码
我们不想弄乱 catch 块中的异常处理代码（如日志记录、电子邮件等）

有人可以发布一些代码示例或文献指针，我们可以使用它们来设计我们的简单异常处理框架吗？

【问题讨论】：

标签： c# .net architecture exception-handling

【解决方案1】：

我们不想将过多的 BLL 信息暴露给外界。
（从其他层到bll都可以）

BLL 本身定义了暴露的内容。确保你展示了你想要看到的东西。

我们不想用 try catch 堆栈弄乱代码

那就不要了。例外就是例外。不要使用它们来控制流量。让他们炸毁。

我们不想在 catch 块中弄乱异常处理代码（如日志记录、电子邮件等）

如果您的逻辑不依赖于异常处理（它不应该）和您的code guards itself（这一点很重要，您的应用程序应该总是在无效状态下崩溃，而不是进一步工作。否则 - 很难理解是什么原因造成的），那么仅使用 1 个错误处理程序包装整个应用程序就足够了，该错误处理程序在必要时转储堆栈跟踪。

例如- 在 .net 中，您可以为此订阅 appdomain unhandled exception event。

我个人在我的 Web 应用程序中使用 ELMAH - app.config 中的几行，我有很好的错误日志，存储在 sqlite 中，可以从 Web 应用程序本身轻松访问。这就是我得到的所有错误处理。

【讨论】：

我不同意让内部异常冒泡的想法。如果从您的代码调用的方法抛出一个表示您的调用者可能想要处理的条件的异常，您必须将异常包装在您自己的一个中，定义条件。如果抽象类 DatabaseWrapper 具有 SqlServerWrapper 和 MySqlWrapper 实现，并且正在为 AcmeDatabase 类编写 AcmeDatabaseWrapepr，则 AcmeDatabasseWrapper 决定让 AcmeDatabaseException 的任何派生向上渗透是决定不让调用者有效地处理异常。
由于它应该是调用者而不是包装器来决定是否应该处理特定情况，因此 AcmeDatabaseWrapper 类应该努力捕获 AcmeDatabase 抛出的所有异常并将它们包装在 DatabaseWrapperException 的派生中，如DatabaseWrapperTableNotFoundException、DatabaseWrapperInvalidQueryException、DatabaseWrapperSystemOnFireException等。
@supercat 异常是特定的通信形式。只有当您无法控制使用您的代码的客户端时，它们才有意义。在常规业务线应用中，无论有多少层，通常你都有这个控制权。我不是在谈论构建框架或类似的东西。
我考虑的不是框架，而是数据库通信层之类的东西。应该可以通过编写新的包装类来添加对其他数据库类的支持，而不必更改应用程序代码来拦截新类型的异常（或以任何其他方式更改它，就此而言，除了让它添加一个新的数据库连接工厂到列表）。
我认为值得一提的是 performance issues 源于冒泡异常。

【解决方案2】：

Eric Lippert has a wonderful article on how to handle exceptions.我觉得会很有用。

【讨论】：

【解决方案3】：

异常处理可以很复杂，但最好的方法是使用一些全局定义。例如，您可以使用任何 AOP 框架构建的方面 - 大多数 IoC 容器的一部分，如 Unity、Windsor Castle、Spring.NET。 AOP 框架的单独类别是 PostSharp，它增加了运行时的编译时间方面。

您还可以查看 Enterprise Library 5.0 及其 Exception handling application block，它允许您开箱即用地进行基于策略的异常处理。

【讨论】：