我们正在重构（当然是重新设计）分层设计中的服务。 我们有服务操作层（BLL），网络抽象层 - >（处理网络代理），数据抽象层。 但我们对我们的异常处理策略感到有点困惑。分层架构中的异常处理
有人可以发布一些代码示例或文献指针，我们可以用它来设计我们简单的异常处理框架吗？
我们不想向BLL公开太多的信息给外部世界。
（从其它层BLL是罚款）
这是BLL本身定义什么是暴露。确保你展示了想要看到的东西。
我们不想杂波与尝试捕捉代码堆栈
那就不要。例外情况是例外情况。不要使用它们来控制流量。让他们爆炸。
我们不想惹异常处理代码（如日志，电子邮件等）在catch块
如果你的逻辑不依赖于异常处理（它不应该）和你code guards itself（这个很重要，你的应用程序应该总是在无效状态下爆炸，而不是进一步工作，否则 - 很难理解是什么导致了什么），那么只用1个错误处理程序包装整个应用程序就足够了，在必要时堆叠跟踪。
例如 - 在.net中，您可以使用订阅appdomain unhandled exception event。
我个人使用ELMAH为我的web应用程序 - 在app.config中有几行，并且我有很好的错误日志，存储在sqlite中，很容易从web应用程序访问。这是关于我得到的所有错误处理。
异常处理可以像你想的那样复杂，但好的方法是使用一些全局定义。例如，您可以使用任何AOP框架构建各个方面 - 大多数IoC容器（如Unity，Windsor Castle，Spring.NET）的一部分。单独的AOP框架类别是PostSharp，它增加了运行时编译时间方面的方面。
此外，您可以检查Enterprise Library 5.0及其Exception handling application block，它允许您立即执行基于策略的异常处理。
伟大的文章 - 感谢您的链接。 – Andez 2017-09-07 19:30:35
我不同意让内部例外冒泡的概念。如果从你的代码中调用的方法抛出一个表示条件的异常，那么你的调用者可能想要处理，你必须把异常包装在你自己的一个中，定义条件。如果抽象类DatabaseWrapper具有实现SqlServerWrapper和MySqlWrapper，并且正在为AcmeDatabase类编写一个AcmeDatabaseWrappr，那么由AcmeDatabasseWrapper决定让AcmeDatabaseException的任何派生过滤都是不让调用方有效处理异常的决定。 – supercat 2011-10-16 17:26:03
由于它应该是调用者，而不是包装器，它决定是否应该处理特定情况，所以AcmeDatabaseWrapper类应该尽力捕获由AcmeDatabase引发的所有异常，并将它们包装在DatabaseWrapperException的衍生物中，例如DatabaseWrapperTableNotFoundException，DatabaseWrapperInvalidQueryException，DatabaseWrapperSystemOnFireException ，等。 – supercat 2011-10-16 17:28:56
@supercat例外是特定形式的通信。只有当你无法控制使用你的代码的客户端时，它们才有意义。在常规业务线应用程序中，无论有多少层，通常都有这种控制。我不是在讨论构建框架或类似的东西。 – 2011-10-17 01:08:33