异 常 处 理 Danny Kalev 翻译： cppbug cpp_bug@hotmail.com
异常处理的性能分析
异常处理机制主要取决于运行期类型检查，当一个异常被抛出，实现必须确定异常是不是从try block中抛出。如果异常是从try block中抛出的话，实现就需要比较异常的类型，试图从当前的作用域中找到匹配的handler。如果找到控制权将会传递给handler。然而这些都是乐观的情况。如果实现没有找到一个匹配的handler的话，或者异常不是从try block中抛出，那么就会进行stack unwinding，这个过程会一直进行下去直到一个匹配的handler被找到为止。当匹配的handler未被找到，terminate()就会被调用，终止程序。
额外的运行期类型信息
异常处理机制为了完成异常和它的handler之间的运行期匹配，它必须储存关于每个异常对象的类型以及每个catch语句的额外信息。因为异常可以是任何类型，并且也可以是多态的，所以它的动态类型信息必须被获得通过使用runtime type information(RTTI)，RTTI给程序在速度和大小上增加了额外的负担。并且只有RTTI还不够，实现也需要运行期代码信息，关于每个函数的结构。这些信息需要拿来确定一个异常是不是从try block中抛出。这个信息可以通过编译器以下面的方式产生：编译器把每个函数体划分为三个部分：第一个部分在try block之外并且没有活动的对象，第二个部分也在try block之外但是有活动的对象而且要通过stack unwinding来进行销毁，第三部分在try block中。
抓住对异常处理的支持
异常处理技术的实现在不同的编译器以及平台下是不一样的。但是它们都会强加额外的负担给程序，即使没有异常被抛出。一些编译器可以选择是否对异常处理进行支持。当异常处理被关掉的时候，那些额外的数据结构，查找表，以及一些附加的代码都不会被生成。然而，关闭异常处理往往很少被选择，因为即使你不直接使用异常，你也会隐含的使用它们：例如operator new,会抛出std::bad_alloc异常；STL容器可能会抛出他们自己的异常；第三方代码库也可能使用异常。因此，只有在你导入纯C代码的时候，才应该考虑关闭异常处理来避免额外的负担。
异常的误用
异常处理并不是用来限制出现错误，一些程序员可能会简单的使用它来作为循环的选择控制结构。例如，一个简单的应用程序让用户输入数据直到一个特定的条件满足：
#include <iostream>
using namespace std;
class Exit{}; //used as exception object
int main()
{
int num;
cout<< "enter a number; 99 to exit" <<endl;
try
{
while (true) //infinitely
{
cin>>num;
if (num == 99)
throw Exit(); //exit the loop
cout<< "you entered: " << num << "enter another number " <<endl;
}
}
catch (Exit& )
{
cout<< "game over" <<endl;
}
return 0;
}
在上面的例子中，程序员把一个无限循环放在了try block中，throw语句终止循环并且把控制权传递给后面的catch语句。这种编程样式不应该被推荐。它的效率会非常低下因为异常处理存在。在上面小的演示程序中，或许仅仅是程序样式的差异，但是在大规模的应用系统中，使用异常处理来作为控制选择控制结构的话，那么将会带来显著的效率损失。
结论
C++的异常处理机制克服了传统方法所带来的问题。它使得程序员从检查函数的返回状态的乏味的代码中解放出来。另外一个重要的优点是自动的stack unwinding，它保证了局部活动对象被正确销毁以及他们的资源被安全释放。
实现异常处理机制并不是一项简单的工作。对获取异常的动态类型的需要使得RTTI被引入C++。异常可以按照种类进行分组，标准异常就是一个很好的例子。在最近几年里，一些异常处理机制已经得到了修正。第一个就是把exception specifications加入到了函数原型中。另一个是function try block的引入，它使得程序能够处理从构造函数体或初始化列表中抛出的异常。
异常处理是一个用来有效的处理运行期错误的非常强大并且灵活的工具。然而使用它也是有代价的。
（全文完）
