条款46: 宁可编译和链接时出错，也不要运行时出错
除了极少数情况下会使C++抛出异常（例如，内存耗尽 ---- 见条款7）外，运行时错误的概念和C++没什么关系，就象在C中一样。没有下溢，上溢，除零检查；没有数组越界检查，等等。一旦程序通过了编译和链接，你就得靠自己了 ---- 一切后果自负。这很象跳伞运动，一些人从中找到了刺激，另一些人则吓得摔成了残废。这一思想背后的动机当然在于效率：没有运行时检查，程序会更小更快。
处理这类事情有另一个不同的方法。一些语言如Smalltalk和LISP通常在编译链接期间只是检查极少一些错误，但却提供了强大的运行时系统来处理执行期间的错误。不象C++，这些语言几乎都是解释型的，在提供额外灵活性的同时，它们也带来了性能上的损失。
不要忘了你是在用C++编程。即使发现Smalltalk/LISP的方法很吸引人，也要忘掉它们。常说要坚持党的路线，现在的情况下，它的含义就是要避免运行时错误。只要有可能，就要让出错检查从运行时退回到链接时，或者，最理想的是，编译时。
这种方法带来的好处不仅仅在于程序的大小和速度，还有可靠性。如果程序通过了编译和链接而没有产生错误信息，你就可以确信程序中没有编译器和链接器能检查得到的任何错误，仅此而已。（当然，另一个可能性是，编译器或链接器有问题，但不要拿这种可能性来困扰我们。）
对于运行时错误来说，情况大不一样。在某次运行期间程序没有产生任何运行时错误，你就能确信另一次不同的运行期内不会产生错误吗？比如：在另一次运行中，你以不同的顺序做事，或者采用不同的数据，或者运行更长或更短时间，等等。你可以不停地测试自己的程序直到面色发紫，但你还是不能覆盖所有的可能性。因而，运行时发现错误比在编译链接期间检查错误更不能让人放心。
通常，对设计做一点小小的改动，就可以在编译期间消除可能产生的运行时错误。这常常涉及到在程序中增加新的数据类型（参见条款M33）。例如，假设想写一个类来表示时间中的日期，最初的做法可能象这样：
class Date {
public:
Date(int day, int month, int year);
...
};
准备实现这个构造函数，面临的一个问题是对day和month值的合法性检查。让我们来看看，对于传给month的值来说，怎么做可以免于对它进行合法性检查呢？
一个明显的办法是采用枚举类型而不用整数：
enum Month { Jan = 1, Feb = 2, ... , Nov = 11, Dec = 12 };
class Date {
public:
Date(int day, Month month, int year);
...
};
遗憾的是，这不会换来多少好处，因为枚举类型不需要初始化：
Month m;
Date d(22, m, 1857); // m是不确定的
所以，Date构造函数还是得验证month参数的值。
既想免除运行时检查，又要保证足够的安全性，你就得用一个类来表示month，你就得保证只有合法的month才被创建：
class Month {
public:
static const Month Jan() { return 1; }
static const Month Feb() { return 2; }
...
static const Month Dec() { return 12; }
int asInt() const // 为了方便，使Month
{ return monthNumber; } // 可以被转换为int
private:
Month(int number): monthNumber(number) {}
const int monthNumber;
};
class Date {
public:
Date(int day, const Month& month, int year);
...
};
这个设计在几个方面的特点综合确定了它的工作方式。首先，Month构造函数是私有的。这防止了用户去创建新的month。可供使用的只能是Month的静态成员函数返回的对象，再加上它们的拷贝。第二，每个Month对象为const，所以它们不能被改变（否则，很多地方会忍不住将一月转换成六月，特别是在北半球）。最后一点，得到Month对象的唯一办法是调用函数或拷贝现有的Month（通过隐式Month拷贝构造函数 ---- 见条款45）。这样，就可以在任何时间任何地方使用Month对象；不必担心无意中使用了没有被初始化的对象。（否则就可能有问题。条款47进行了说明）
有了这些类，用户几乎不可能指定一个非法的month，甚至完全不可能 ---- 如果不出现下面这种可恶的情况的话：
Month *pm; // 定义未被初始化的指针
Date d(1, *pm, 1997); // 使用未被初始化的指针!
但这种情况所涉及的是另一个问题，即通过未被初始化的指针取值，其结果是不可确定的。（参见条款3，看看我对 "不确定行为" 的感受）遗憾的是，我没有办法来防止或检查这种异端行为。但是，如果假设这种情况永远不会发生，或者如果我们不考虑这种情况下软件的行为，Date构造函数对它的Month参数就可以免于合法性检查。另一方面，构造函数还是必须检查day参数的合法性 ---- 九月，四月，六月和十一月各有多少天呢？
Date的例子将运行时检查用编译时检查来取代。你可能想知道什么时候可以使用链接时检查。实际上，不是经常这么做。C++用链接器来保证所需要的函数只被定义一次（参见条款45，"需要" 一个函数会带来什么）。它还使用链接器来保证静态对象（参见条款47）只被定义一次。你可以用同样的方法使用链接器。例如，条款27说明，对于一个显式声明的函数，如果想有意禁止对它进行定义，链接器检查就很有用。
但不要过于强求。想消除所有的运行检查是不切实际的。例如，任何允许交互式输入的程序都要进行输入验证。同样地，某个类中如果包含需要执行上下限检查的数组，每次访问数组时就要对数组下标进行检查。尽管如此，将检查从运行时转移到编译或链接时一直是值得努力的目标，只要实际可行，就要追求这一目标。这样做的奖赏是，程序会更小，更快，更可靠。
