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风格，例如在容器中注册异常记录器拦截器。)
