几年前，当异常规格这个概念首次被提出时，它们被认为是很有前景的。但是，在一个程序语言的自然发展过程中，刚开始觉得很有前景的东西逐渐被淘汰是常有的事情。让我们来看看为什么异常规格会失去原有的光彩。
在C++的析构，构造和其他成员函数中，明确的指出告诉用户哪个函数会掷出哪些异常，例如：
class A{
public:
A() throw();
// seemingly a good idea
~A() throw();
};
这个程序的问题是异常规格迫使编译器花费宝贵的时间去检查函数没有违背它。
记住一个含有空异常规格的函数也可以掷出异常。例如，如果一个构造函数试图用自由存储的方式分配内存但是失败了，一个异常就会掷出，因此，它违反了构造函数的异常规格。
为了解决这些问题，编译器必须分析每个函数的构造规格。这些构造规格在一些特殊的保护块中，如果发生了未批准的异常，这些块就会调用unexpected()，这个对执行时间的影响是不可忽视的，更糟糕的是，这些检查仅有一点价值，终于，总会有一个违反了的异常规格导致了程序的终止。
这个例子的教训是：无论流行的C++书上怎么写，也不要总是使用异常规格。
