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

核心提示： 很多我所推荐的方法，可以更简单的帮助你来确保进行强异常保证，Effective C# 原则45：选择强异常来保护程序(2)，你程序使用的数据元素应该存为一个恒定的类型(参见原则6和原则7)，如果你组并这两个原则，如果某个异常在任何情况下都要终止程序，这就没有意义做强异常保证了，对程序状态进

很多我所推荐的方法，可以更简单的帮助你来确保进行强异常保证。你程序使用的数据元素应该存为一个恒定的类型(参见原则6和原则7)。如果你组并这两个原则，对程序状态进行的任何修改都可以在任何可能引发异常的操作完成后简单的发生。常规的原则是让任何数据的修改都遵守下面的原则：

1、对可能要修改的数据进行被动式的拷贝。

2、在拷贝的数据上完成修改操作。这包括任何可能异常异常的操作。

3、把临时的拷贝数据与源数据进行交换。 这个操作决不能发生任何异常。

做为一个例子，下面的代码用被动的拷贝方式更新了一个雇员的标题和工资 ：

public void PhysicalMove( string title, decimal newPay )
{
　// Payroll data is a struct:
　// ctor will throw an exception if fields aren't valid.
　PayrollData d = new PayrollData( title, newPay,
　　this.payrollData.DateOfHire );
　// if d was constructed properly, swap:
　this.payrollData = d;
}

有些时候，这种强保证只是效率很低而不被支持，而且有些时候，你不能支持不发生潜在BUG的强保证。开始的那个也是最简单的那个例子是一个循环构造。当上面的代码在一个循环里，而这个循环里有可能引发程序异常的修改，这时你就面临一个困难的选择：你要么对循环里的所有对象进行拷贝，或者降低异常保证，只对基本保证提供支持。这里没有固定的或者更好的规则，但在托管环境里拷贝堆上分配的对象，并不是像在本地环境上那开销昂贵。在.Net里，大量的时间都花在了内存优化上。我喜欢选择支持强异常保证，即使这意味要拷贝一个大的容器：获得从错误中恢复的能力，比避免拷贝获得小的性能要划算得多。在特殊情况下，不要做无意义的拷贝。如果某个异常在任何情况下都要终止程序，这就没有意义做强异常保证了。我们更关心的是交换引用类型数据会让程序产生错误。考虑这个例子：