.net – Microsoft异常处理块 – 它不是一个完美的例子吗？

自微软推出应用程序块以来，我一直在碰到使用 Exception Handling Application Block的用户。我最近仔细看了一下，总结了基本功能，如下所示(如果你已经知道它是什么，请跳过下面的程序块) )：

The exception handling application block aims to centralize and make fully configurable with config files the following 07001:

• Logging an Exception
• Replacing an Exception
• Wrapping an Exception
• Propagating an Exception
• etc.

The library does that by having you modify your try catch blocks as follows:

06000

Based on what is specified in the app.config for the policy name (07002),HandleException will either …

• throw a completely new exception (replace the original exception)
• wrap the original exception in a new one and throw that
• swallow the exception (i.e. do nothing)
• have you rethrow the original exception

Additionally you can also configure it to do more stuff beforehand (e.g. log the exception).

现在这里是我的问题：我完全不知道如何更改，包装，吞下或重新引导异常，使它可以被配置成有益处。根据我的经验，此决定必须在您编写代码时进行，因为在更改异常处理行为时，通常必须更改周围或调用代码。

例如，当您重新配置时，您的代码可能开始行为不正确，以便在特定时刻抛出的特定异常现在被吞入，而不是重新引导(在发生异常时，可能会有catch块之后的代码不能被执行)。异常处理中的所有其他可能的更改也是如此(例如替换 – > rethrow，swallow – > wrap)。

所以，对我来说，底线是异常处理块解决了实际上不存在的问题。异常记录和通知位是好的，但不是所有其他的东西只是一个完美的例子overengineering？

如果您对控制流使用异常，那么您应该远离基于策略的异常处理。

但是，如果您想将其视为不可恢复(后台任务失败，套接字已断开连接，文件已删除等)，则可能需要配置基于策略的异常处理。

例如，如果您正在开发API，则可能希望您的API中的每个函数仅抛出标准异常(ArgumentException等)，以及在内部非标准的情况下您自己的库特定异常异常(例如MyLibraryException)。在这种情况下，重要的是某些事情无法正常运行。你不是挑选出异常，弄清楚出了什么问题。你只是承认事情出了问题，你现在应该做点什么。

那个东西应该是可配置的，因为你做的并不重要。向用户显示消息框？模态还是非模态？记录异常？你想如何记录异常？调用日志Web服务？追加到日志文件？写入Windows事件日志？在数据库中插入一个条目？将条目插入两个数据库？你的应用程序的其余部分并不重要。如何处理异常的选择与应用程序的其余部分完全正交。

(除此之外，这不是我将如何处理可配置的基于策略的异常处理，我更倾向于采用AOP风格，例如在容器中注册异常记录器拦截器。)