Effective C# 原则45：选择强异常来保护程序

核心提示： 合并修改到当前的DataSet上，就让所有的用户保持可用的引用，Effective C# 原则45：选择强异常来保护程序(4)，而且内部的DataSet内容已经更新，在一般情况下，而且它们应该在不充许任何异常逃出环境的情况下完成任务，最后一句话：小心对引用类型的交换，你不能修正像这样的引用

合并修改到当前的DataSet上，就让所有的用户保持可用的引用，而且内部的DataSet内容已经更新。

在一般情况下，你不能修正像这样的引用类型交换，然后还想确保用户拥有当前的对象拷贝。交换工作只对值类型有效，如果你遵守原则6，这应该是足够了。

最后，也是最严格的，就是无抛出保证。无抛出保证听起来很优美，就像是：一个方法是无抛出保证，如果它保证总是完成任务，而且不会在方法里发生任何异常。在大型程序中，对于所有的常规问题并不是实用的。然而，如果在一个小的范围上，方法必须强制无抛出保证。析构和处理方法就必须保证无异常抛出。在这两种情况下，抛出任何异常会引发更多的问题，还不如做其它的选择。在析构时，抛出异常中止程序就不能进一步的做清理工作了。

如果在处理方法中抛出异常，系统现在可能有两个异常在运行系统中。.Net环境丢失前面的一个异常然后抛出一个新的异常。你不能在程序的任何地方捕获初始的异常，它被系统干掉了。这样，你又如何能从你看不见的错误中恢复呢？

最后一个要做无抛出保证的地方是在委托对象上。当一个委托目标抛出异常时，在这个多播委托上的其它目标就不能被调用了。对于这个问题的唯一方法就是确保你在委托目标上不抛出任何异常(译注：我不造成这种做法，而且谁又能保证在委托目标上不 出现异常呢？)。让我们再重申一下：委托目标(包括事件句柄)应该不抛出异常。这样做就意味关引发事件的代码不应该参与到强异常保证中。但在这里，我将要修改这一建议。原则21告诉你可以调用委托，因此你可以从一个异常中恢复。想也想得到，并不是每个人都这样做，所以你应该在委托句柄上抛出异常。只在要你在委托上不抛出异常，并不意味着其它人也遵守这一建议，在你自己的委托调用上，不能指望它是无抛出的保证。这主是被动式程序设计：你应该尽可能做原最好，因为其他程序可能做了他们能做的最坏的事。

异常列在应用程序的控制流程上引发了一系列的改变，在最糟糕的情况下，任何事情都有可能发生，或者任何事情也有可能不发生。在异常发生时，唯一可以知道哪些事情发生，哪些事情没有发生的方法就是强制强异常保证。当一个操作不管是完成还是没有完成时都不做任何修改。构造和Dispose()以及委托目标是特殊的情况，而且它们应该在不充许任何异常逃出环境的情况下完成任务。最后一句话：小心对引用类型的交换，它可能会引发大量潜在的BUG。