http://blog.sina.com.cn/s/blog_a9303fd901018ost.html
大部分内容转自：http://blog.csdn.net/codestinity/article/details/6877581
一、简单的例子
首先通过一个简单的例子来熟悉C++ 的 try/catch/throw:
1 #include<iostream.h> //包含头文件
2 #include<stdlib.h>
3 double fuc(double x, double y) //定义函数
4 {
5 if(y==0)
6 {
7 throw y; //除数为0，抛出异常
8 }
9 return x/y; //否则返回两个数的商
10 }
11 void main()
12 {
13 double res;
14 try //定义异常
15 {
16 res=fuc(2,3);
17 cout<<"The result of x/y is : "<<res<<endl;
18 res=fuc(4,0); //出现异常
19 }
20 catch(double) //捕获并处理异常
21 {
22 cerr<<"error of dividing zero.
";
23 exit(1); //异常退出程序
24 }
25 }
catch 的数据类型需要与throw出来的数据类型相匹配的。
二、catch（...）的作用
catch(…)能够捕获多种数据类型的异常对象，所以它提供给程序员一种对异常对象更好的控制手段，使开发的软件系统有很好的可靠性。因此一个比较有经验的程序员通常会这样组织编写它的代码模块，如下：
void Func()
{
try
{
// 这里的程序代码完成真正复杂的计算工作，这些代码在执行过程中
// 有可能抛出DataType1、DataType2和DataType3类型的异常对象。
}
catch(DataType1& d1)
{
}
catch(DataType2& d2)
{
}
catch(DataType3& d3)
{
}
// 注意上面try block中可能抛出的DataType1、DataType2和DataType3三
// 种类型的异常对象在前面都已经有对应的catch block来处理。但为什么
// 还要在最后再定义一个catch(…) block呢？这就是为了有更好的安全性和
// 可靠性，避免上面的try block抛出了其它未考虑到的异常对象时导致的程
// 序出现意外崩溃的严重后果，而且这在用VC开发的系统上更特别有效，因
// 为catch(…)能捕获系统出现的异常，而系统异常往往令程序员头痛了，现
// 在系统一般都比较复杂，而且由很多人共同开发，一不小心就会导致一个
// 指针变量指向了其它非法区域，结果意外灾难不幸发生了。catch(…)为这种
// 潜在的隐患提供了一种有效的补救措施。
catch(…)
{
}
}
三、异常中采用面向对象的处理
首先看下面的例子：
void OpenFile(string f)
{
try
{
// 打开文件的操作，可能抛出FileOpenException
}
catch(FileOpenException& fe)
{
// 处理这个异常，如果这个异常可以很好的得以恢复，那么处理完毕后函数
// 正常返回；否则必须重新抛出这个异常，以供上层的调用函数来能再次处
// 理这个异常对象
int result = ReOpenFile(f);
if (result == false) throw;
}
}
void ReadFile(File f)
{
try
{
// 从文件中读数据，可能抛出FileReadException
}
catch(FileReadException& fe)
{
// 处理这个异常，如果这个异常可以很好的得以恢复，那么处理完毕后函数
// 正常返回；否则必须重新抛出这个异常，以供上层的调用函数来能再次处
// 理这个异常对象
int result = ReReadFile(f);
if (result == false) throw;
}
}
void WriteFile(File f)
{
try
{
// 往文件中写数据，可能抛出FileWriteException
}
catch(FileWriteException& fe)
{
// 处理这个异常，如果这个异常可以很好的得以恢复，那么处理完毕后函数
// 正常返回；否则必须重新抛出这个异常，以供上层的调用函数来能再次处理这个异常对象
int result = ReWriteFile(f);
if (result == false) throw;
}
}
void Func()
{
try
{
// 对文件进行操作，可能出现FileWriteException、FileWriteException
// 和FileWriteException异常
OpenFile(…);
ReadFile(…);
WriteFile(…);
}
// 注意：FileException是FileOpenException、FileReadException和FileWriteException
// 的基类，因此这里定义的catch(FileException& fe)能捕获所有与文件操作失败的异
// 常。
catch(FileException& fe)
{
ExceptionInfo* ef = fe.GetExceptionInfo();
cout << “操作文件时出现了不可恢复的错误，原因是：”<< fe << endl;
}
}
下面是更多面向对象和异常处理结合的例子：
#include <iostream.h>
class ExceptionClass
{
char* name;
public:
ExceptionClass(const char* name="default name")
{
cout<<"Construct "<<name<<endl;
this->name=name;
}
~ExceptionClass()
{
cout<<"Destruct "<<name<<endl;
}
void mythrow()
{
throw ExceptionClass("my throw");
}
}
void main()
{
ExceptionClass e("Test");
try
{
e.mythrow();
}
catch(...)
{
cout<< "cattch in main"<<endl;
}
}
这是输出信息：
[root@localhost throw]# ./tst
Construct Test
Construct my throw
cattch in main
Destruct my throw
Destruct Test
======================================
不过一般来说我们可能更习惯于把会产生异常的语句和要throw的异常类分成不同的类来写，下面的代码可以是我们更愿意书写的：
class ExceptionClass
{
public:
ExceptionClass(const char* name="Exception Default Class")
{
cout<<"Exception Class Construct String"<<endl;
}
~ExceptionClass()
{
cout<<"Exception Class Destruct String"<<endl;
}
void ReportError()
{
cout<<"Exception Class:: This is Report Error Message"<<endl;
}
};
class ArguClass
{
char* name;
public:
ArguClass(char* name="default name")
{
cout<<"Construct String::"<<name<<endl;
this->name=name;
}
~ArguClass()
{
cout<<"Destruct String::"<<name<<endl;
}
void mythrow()
{
throw ExceptionClass("my throw");
}
};
_tmain()
{
ArguClass e("haha");
try
{
e.mythrow();
}
catch(int)
{
cout<<"If This is Message display screen, This is a Error!!"<<endl; //这行不会执行
}
catch(ExceptionClass pTest)
{
pTest.ReportError();
}
catch(...)
{
cout<<"***************"<<endl;
}
}
输出Message：
Construct String::haha
Exception Class Construct String
Exception Class Destruct String
Exception Class:: This is Report Error Message
Exception Class Destruct String
Destruct String::haha
四、构造和析构中的异常抛出
先看个程序，假如我在构造函数的地方抛出异常，这个类的析构会被调用吗？可如果不调用，那类里的东西岂不是不能被释放了？
#include <iostream.h>
#include <stdlib.h>
class ExceptionClass1
{
char* s;
public:
ExceptionClass1()
{
cout<<"ExceptionClass1()"<<endl;
s=new char[4];
cout<<"throw a exception"<<endl;
throw 18;
}
~ExceptionClass1()
{
cout<<"~ExceptionClass1()"<<endl;
delete[] s;
}
};
void main()
{
try
{
ExceptionClass1 e;
}
catch(...)
{}
}
结果为：
ExceptionClass1()
throw a exception
在这两句输出之间，我们已经给S分配了内存，但内存没有被释放（因为它是在析构函数中释放的）。应该说这符合实际现象，因为对象没有完整构造。
为了避免这种情况，我想你也许会说：应避免对象通过本身的构造函数涉及到异常抛出。即：既不在构造函数中出现异常抛出，也不应在构造函数调用的一切东西中出现异常抛出。
但是在C++中可以在构造函数中抛出异常，经典的解决方案是使用STL的标准类auto_ptr。
那么，在析构函数中的情况呢？我们已经知道，异常抛出之后，就要调用本身的析构函数，如果这析构函数中还有异常抛出的话，则已存在的异常尚未被捕获，会导致异常捕捉不到。
五、标准C++异常类
标准异常都派生自一个公共的基类exception。基类包含必要的多态性函数提供异常描述，可以被重载。下面是exception类的原型：
class exception
{
public:
exception() throw();
exception(const exception& rhs) throw();
exception& operator=(const exception& rhs) throw();
virtual ~exception() throw();
virtual const char *what() const throw();
};
C++有很多的标准异常类：
namespace std
{
//exception派生
class logic_error; //逻辑错误,在程序运行前可以检测出来
//logic_error派生
class domain_error; //违反了前置条件
class invalid_argument; //指出函数的一个无效参数
class length_error; //指出有一个超过类型size_t的最大可表现值长度的对象的企图
class out_of_range; //参数越界
class bad_cast; //在运行时类型识别中有一个无效的dynamic_cast表达式
class bad_typeid; //报告在表达试typeid(*p)中有一个空指针p
//exception派生
class runtime_error; //运行时错误,仅在程序运行中检测到
//runtime_error派生
class range_error; //违反后置条件
class overflow_error; //报告一个算术溢出
class bad_alloc; //存储分配错误
}
标准库异常类定义在以下四个头文件中
1、exception头文件：定义了最常见的标准异常类，其类名为exception。只通知异常的产生，但不会提供更多的信息
2、stdexcept头文件定义了以下几种常见异常类
函数 功能或作用
exception 最常见的问题
runtime_error 运行时错误：仅在运行时才能检测到的问题
range_error 运行时错误：生成的结果超出了有意义的值域范围
overflow_error 运行时错误：计算上溢
underflow_error 运行时错误：计算下溢
logic_error 逻辑错误：可在运行前检测到的问题
domain_error 逻辑错误：参数的结果值不存在
invalid_argument 逻辑错误：不合适的参数
length_error 逻辑错误：试图生成一个超出该类型最大长度的对象
out_of_range 逻辑错误：使用一个超出有效范围的值
3、new头文件定义了bad_alloc异常类型，提供因无法分配内存而由new抛出的异常
4、type_info头文件定义了bad_cast异常类型（要使用type_info必须包含typeinfo头文件）
下面是使用异常类的例子：
首先，我定义了几个异常类，这些类也可以从标准异常类进行派生，如下
class BadInitializers
{
public:
BadInitializers() {}
};
class OutOfBounds
{
public:
OutOfBounds(int i) { cout<<"Size "<<i<<" is illegal!!!"<<endl; }
};
class SizeMismatch
{
public:
SizeMismatch() {}
};
然后要在程序中需要的地方使用throw来抛出异常类，两个抛出异常类的例子如下
template <class T>
Array1D<T>::Array1D(int sz)
{
if(sz<0)
{
//throw BadInitializers();
throw invalid_argument("Size has to be bigger than 0!!!");
}
size=sz;
element=new T[size];
}
template <class T>
T &Array1D<T>::operator[](int i) const
{
if(i<0||i>=size)
{
throw OutOfBounds(i);
}
return element[i];
}
然后在主程序中使用try...catch...来捕获异常，并进行相应的处理，如下
try
{
int i=0;
Array1D<int> a1(5);
a1[0]=1;
a1[1]=3;
a1[2]=5;
a1[3]=7;
a1[4]=8;
Array1D<int> a2(a1);
for(i=0;i<a2.Size();i++)
{
cout<<a2[i]<<" ";
}
cout<<endl;
Array1D<int> a3(5);
a3=a1+a2;
cout<<a3;
}
catch(BadInitializers)
{
cout<<"Error:BadInitializers!!!"<<endl;
}
catch(OutOfBounds &e)
{
cout<<"Error:OutOfBounds!!!"<<endl;
}
catch(SizeMismatch &e)
{
cout<<"Error:SizeMismatch!!!"<<endl;
}
catch(invalid_argument &e)
{
cout<<"Error:"<<e.what()<<endl;
}
catch(...)
{
cout<<"An unknown error!!!"<<endl;
}
六、try finally使用
__try
{
file://保护块
}
__finally
{
file://结束处理程序
}
在上面的代码段中，操作系统和编译程序共同来确保结束处理程序中的__f i n a l l y代码块能够被执行，不管保护体（t r y块）是如何退出的。不论你在保护体中使用r e t u r n，还是g o t o，或者是longjump，结束处理程序（f i n a l l y块）都将被调用。
我们来看一个实列：（返回值：10, 没有Leak，性能消耗：小）
DWORD Func_SEHTerminateHandle()
{
DWORD dwReturnData = 0;
HANDLE hSem = NULL;
const char* lpSemName = "TermSem";
hSem = CreateSemaphore(NULL, 1, 1, lpSemName);
__try
{
WaitForSingleObject(hSem,INFINITE);
dwReturnData = 5;
}
__finally
{
ReleaseSemaphore(hSem,1,NULL);
CloseHandle(hSem);
}
dwReturnData += 5;
return dwReturnData;
}
这段代码应该只是做为一个基础函数，我们将在后面修改它，来看看结束处理程序的作用：
====================
在代码加一句：（返回值：5, 没有Leak，性能消耗：中下）
DWORD Func_SEHTerminateHandle()
{
DWORD dwReturnData = 0;
HANDLE hSem = NULL;
const char* lpSemName = "TermSem";
hSem = CreateSemaphore(NULL, 1, 1, lpSemName);
__try
{
WaitForSingleObject(hSem,INFINITE);
dwReturnData = 5;
return dwReturnData;
}
__finally
{
ReleaseSemaphore(hSem,1,NULL);
CloseHandle(hSem);
}
dwReturnData += 5;
return dwReturnData;
}
在try块的末尾增加了一个return语句。这个return语句告诉编译程序在这里要退出这个函数并返回dwTemp变量的内容，现在这个变量的值是5。但是，如果这个return语句被执行，该线程将不会释放信标，其他线程也就不能再获得对信标的控制。可以想象，这样的执行次序会产生很大的问题，那些等待信标的线程可能永远不会恢复执行。
通过使用结束处理程序，可以避免return语句的过早执行。当return语句试图退出try块时，编译程序要确保finally块中的代码首先被执行。要保证finally块中的代码在try块中的return语句退出之前执行。在程序中，将ReleaseSemaphore的调用放在结束处理程序块中，保证信标总会被释放。这样就不会造成一个线程一直占有信标，否则将意味着所有其他等待信标的线程永远不会被分配CPU时间。
在finally块中的代码执行之后，函数实际上就返回。任何出现在finally块之下的代码将不再执行，因为函数已在try块中返回。所以这个函数的返回值是5，而不是10。
读者可能要问编译程序是如何保证在try块可以退出之前执行finally块的。当编译程序检查源代码时，它看到在try块中有return语句。这样，编译程序就生成代码将返回值（本例中是5）保存在一个编译程序建立的临时变量中。编译程序然后再生成代码来执行f i n a l l y块中包含的指令，这称为局部展开。更特殊的情况是，由于try块中存在过早退出的代码，从而产生局部展开，导致系统执行finally块中的内容。在finally块中的指令执行之后，编译程序临时变量的值被取出并从函数中返回。
可以看到，要完成这些事情，编译程序必须生成附加的代码，系统要执行额外的工作。
finally块的总结性说明
我们已经明确区分了强制执行finally块的两种情况：
• 从try块进入finally块的正常控制流。
• 局部展开：从try块的过早退出（goto、long jump、continue、break、return等）强制控制转移到finally块。
第三种情况，全局展开（ global unwind），这个以后再看。
七、C++异常参数传递
从语法上看，在函数里声明参数与在catch子句中声明参数是一样的，catch里的参数可以是值类型，引用类型，指针类型。例如：
try
{
.....
}
catch(A a)
{
}
catch(B& b)
{
}
catch(C* c)
{
}
尽管表面是它们是一样的，但是编译器对二者的处理却又很大的不同。调用函数时，程序的控制权最终还会返回到函数的调用处，但是抛出一个异常时，控制权永远不会回到抛出异常的地方。
class A;
void func_throw()
{
A a;
throw a; //抛出的是a的拷贝，拷贝到一个临时对象里
}
try
{
func_throw();
}
catch(A a) //临时对象的拷贝
{
}
当我们抛出一个异常对象时，抛出的是这个异常对象的拷贝。当异常对象被拷贝时，拷贝操作是由对象的拷贝构造函数完成的。该拷贝构造函数是对象的静态类型(static type)所对应类的拷贝构造函数，而不是对象的动态类型(dynamic type)对应类的拷贝构造函数。此时对象会丢失RTTI信息。
异常是其它对象的拷贝，这个事实影响到你如何在catch块中再抛出一个异常。比如下面这两个catch块，乍一看好像一样:
catch (A& w) // 捕获异常
{
// 处理异常
throw; // 重新抛出异常，让它继续传递
}
catch (A& w) // 捕获Widget异常
{
// 处理异常
throw w; // 传递被捕获异常的拷贝
}
第一个块中重新抛出的是当前异常(current exception),无论它是什么类型。（有可能是A的派生类）
第二个catch块重新抛出的是新异常，失去了原来的类型信息。
一般来说，你应该用throw来重新抛出当前的异常，因为这样不会改变被传递出去的异常类型，而且更有效率，因为不用生成一个新拷贝。
看看以下这三种声明:
catch (A w) ... // 通过传值
catch (A& w) ... // 通过传递引用，一个被异常抛出的对象(总是一个临时对象)可以通过普通的引用捕获
catch (const A& w) ... //const引用
回到异常对象拷贝上来。我们知道，当用传值的方式传递函数的参数，我们制造了被传递对象的一个拷贝，并把这个拷贝存储到函数的参数里。同样我们通过传值的方式传递一个异常时，也是这么做的当我们这样声明一个catch子句时:
catch (A w) ... // 通过传值捕获
会建立两个被抛出对象的拷贝，一个是所有异常都必须建立的临时对象，第二个是把临时对象拷贝进w中。实际上，编译器会优化掉一个拷贝。同样，当我们通过引用捕获异常时，
catch (A& w) ... // 通过引用捕获
catch (const A& w) ... //const引用捕获
这仍旧会建立一个被抛出对象的拷贝:拷贝是一个临时对象。相反当我们通过引用传递函数参数时，没有进行对象拷贝。话虽如此，但是不是所有编译器都如此。
另外，通过指针抛出异常与通过指针传递参数是相同的。不论哪种方法都是一个指针的拷贝被传递。你不能认为抛出的指针是一个指向局部对象的指针，因为当异常离开局部变量的生存空间时，该局部变量已经被释放。Catch子句将获得一个指向已经不存在的对象的指针。这种行为在设计时应该予以避免。
另外一个重要的差异是在函数调用者或抛出异常者与被调用者或异常捕获者之间的类型匹配的过程不同。在函数传递参数时，如果参数不匹配，那么编译器会尝试一个类型转换，如果存在的话。而对于异常处理的话，则完全不是这样。见一下的例子：
void func_throw()
{
CString a;
throw a; //抛出的是a的拷贝，拷贝到一个临时对象里
}
try
{
func_throw();
}
catch(const char* s)
{
}
抛出的是CString，如果用const char*来捕获的话，是捕获不到这个异常的。
尽管如此，在catch子句中进行异常匹配时可以进行两种类型转换。第一种是基类与派生类的转换，一个用来捕获基类的catch子句也可以处理派生类类型的异常。反过来，用来捕获派生类的无法捕获基类的异常。
第二种是允许从一个类型化指针(typed pointer)转变成无类型指针(untyped pointer)，所以带有const void* 指针的catch子句能捕获任何类型的指针类型异常:
catch (const void*) ... //可以捕获所有指针异常
另外，你还可以用catch(...)来捕获所有异常，注意是三个点。
传递参数和传递异常间最后一点差别是catch子句匹配顺序总是取决于它们在程序中出现的顺序。因此一个派生类异常可能被处
理其基类异常的catch子句捕获，这叫异常截获，一般的编译器会有警告。
class A {
public:
A()
{
cout << "class A creates" << endl;
}
void print()
{
cout << "A" << endl;
}
~A()
{
cout << "class A destruct" << endl;
}
};
class B: public A
{
public:
B()
{
cout << "class B create" << endl;
}
void print()
{
cout << "B" << endl;
}
~B()
{
cout << "class B destruct" << endl;
}
};
void func()
{
B b;
throw b;
}
try
{
func();
}
catch( B& b) //必须将B放前面，如果把A放前面，B放后面，那么B类型的异常会先被截获。
{
b.print();
}
catch (A& a)
{
a.print() ;
}
http://blog.csdn.net/windhaunting/article/details/4735338
try{} catch(…){}
以前都是用try{} catch(…){}来捕获C++中一些意想不到的异常， 今天看了Winhack的帖子才知道，这种方法在VC中其实是靠不住的。例如下面的代码：
- try
- {
- BYTE* pch ;
- pch = ( BYTE* )00001234 ; //给予一个非法地址
- *pch = 6 ; //对非法地址赋值，会造成Access Violation 异常
- }
- catch(...)
- {
- AfxMessageBox( "catched" ) ;
- }
这段代码在debug下没有问题，异常会被捕获，会弹出”catched”的消息框。 但在Release方式下如果选择了编译器代码优化选项，则VC编译器会去搜索try块中的代码， 如果没有找到throw代码， 他就会认为try catch结构是多余的， 给优化掉。 这样造成在Release模式下，上述代码中的异常不能被捕获，从而迫使程序弹出错误提示框退出。
那么能否在release代码优化状态下捕获这个异常呢， 答案是有的。 就是__try, __except结构， 上述代码如果改成如下代码异常即可捕获。
- __try
- {
- BYTE* pch ;
- pch = ( BYTE* )00001234 ; //给予一个非法地址
- *pch = 6 ; //对非法地址赋值，会造成Access Violation 异常
- }
- __except( EXCEPTION_EXECUTE_HANDLER )
- {
- AfxMessageBox( "catched" ) ;
- }
但是用__try, __except块还有问题， 就是这个不是C++标准， 而是Windows平台特有的扩展。 而且如果在使用过程中涉及局部对象析构函数的调用，则会出现C2712 的编译错误。 那么还有没有别的办法呢？
当然有， 就是仍然使用C++标准的try{}catch(..){}， 但在编译命令行中加入 /EHa 的参数。这样VC编译器不会把try catch模块给优化掉了。
找到一篇比较好的英文文章谈这个问题： http://members.cox.net/doug_web/eh.htm
用C++10 年多了 ， 居然这么基础的问题都搞错， 真是汗颜。 要加紧学习啊， Stay Hungry, Stay Foolish!
Written by oldmonk on 九月 11th, 2006 with 2 comments.
Read more articles on IT.
http://se.csai.cn/ExpertEyes/No138.htm
C++中catch(…)如何使用
上一篇文章中详细讲了讲C++异常处理模型的trycatch使用语法，其中catch关键字是用来定义catch block的，它后面带一个参数，用来与异常对象的数据类型进行匹配。注意catch关键字只能定义一个参数，因此每个catch block只能是一种数据类型的异常对象的错误处理模块。如果要想使一个catch block能抓获多种数据类型的异常对象的话，怎么办？C++标准中定义了一种特殊的catch用法，那就是” catch(…)”。
感性认识
1、catch(…)到底是一个什么样的东东，先来个感性认识吧！看例子先：
int main()
{
try
{
cout << "在 try block 中, 准备抛出一个异常." << endl;
//这里抛出一个异常（其中异常对象的数据类型是int，值为1）
throw 1;
}
//catch( int& value )
//注意这里catch语句
catch( …)
{
cout << "在 catch(…) block 中, 抛出的int类型的异常对象被处理" << endl;
}
}
2、哈哈！int类型的异常被catch(…)抓获了，再来另一个例子：
int main()
{
try
{
cout << "在 try block 中, 准备抛出一个异常." << endl;
//这里抛出一个异常（其中异常对象的数据类型是double，值为0.5）
throw 0.5;
}
//catch( double& value )
//注意这里catch语句
catch( …)
{
cout << "在 catch(…) block 中, double类型的异常对象也被处理" << endl;
}
}
3、同样，double类型的异常对象也被catch(…)块抓获了。是的，catch(..)能匹配成功所有的数据类型的异常对象，包括C++语言提 供所有的原生数据类型的异常对象，如int、double，还有char*、int*这样的指针类型，另外还有数组类型的异常对象。同时也包括所有自定义 的抽象数据类型。例程如下：
int main()
{
try
{
cout << "在 try block 中, 准备抛出一个异常." << endl;
//这里抛出一个异常（其中异常对象的数据类型是char*）
char* p=0;
throw p;
}
//catch( char* value )
//注意这里catch语句
catch( …)
{
cout << "在 catch(…) block 中, char*类型的异常对象也被处理" << endl;
}
}
int main()
{
try
{
cout << "在 try block 中, 准备抛出一个异常." << endl;
//这里抛出一个异常（其中异常对象的数据类型是int[]）
int a[4];
throw a;
}
//catch( int value[] )
//注意这里catch语句
catch( …)
{
cout << "在 catch(…) block 中, int[]类型的异常对象也被处理" << endl;
}
}
4、对于抽象数据类型的异常对象。catch(…)同样有效，例程如下：
class MyException
{
public:
protected:
int code;
};
int main()
{
try
{
cout << "在 try block 中, 准备抛出一个异常." << endl;
//这里抛出一个异常（其中异常对象的数据类型是MyException）
throw MyException();
}
//catch(MyException& value )
//注意这里catch语句
catch( …)
{
cout << "在catch(…) block中, MyException类型的异常对象被处理" << endl;
}
}
对catch(…)有点迷糊？
1、究竟对catch(…)有什么迷糊呢？还是看例子先吧！
void main()
{
int* p = 0;
try
{
// 注意：下面这条语句虽然不是throw语句，但它在执行时会导致系统
// 出现一个存储保护错误的异常（access violation exception）
*p = 13; // causes an access violation exception;
}
catch(...)
{
//catch(…)能抓获住上面的access violation exception异常吗？
cout << "在catch(…) block中" << endl;
}
}
请问上面的程序运行时会出现什么结果吗？catch(…)能抓获住系统中出现的access violation exception异常吗？朋友们！和我们的主人公阿愚一样，自己动手去测试一把！
结果又如何呢？实际上它有两种不同的运行结果，在window2000系统下用VC来测试运行这个小程序时，发现程序能输出"在catch(…) block中"的语句在屏幕上，也即catch(…) 能成功抓获住系统中出现的access violation exception异常，很厉害吧！但如果这个同样的程序在linux下用gcc编译后运行时，程序将会出现崩溃，并在屏幕上输出”segment fault”的错误信息。
主人公阿愚有点急了，也开始有点迷糊了，为什么？为什么？为什么同样一个程序在两种不同的系统上有不同的表现呢？其原因就是：对于这种由于硬件或操作 系统出现的系统异常（例如说被零除、内存存储控制异常、页错误等等）时，window2000系统有一个叫做结构化异常处理（Structured Exception Handling，SEH）的机制，这个东东太厉害了，它能和VC中的C++异常处理模型很好的结合上（实际上VC实现的C++异常处理模型很大程度上建 立在SEH机制之上的，或者说它是SEH的扩展，后面文章中会详细阐述并分析这个久富盛名的SEH，看看catch(…)是如何神奇接管住这种系统异常出 现后的程序控制流的，不过这都是后话）。而在linux系统下，系统异常是由信号处理编程方法来控制的（信号处理编程，signal processing progamming。在介绍unix和linux下如何编程的书籍中，都会有对信号处理编程详细的介绍，当然执著的主人公阿愚肯定对它也不会放过，会深 入到unix沿袭下来的信号处理编程内部的实现机制，并尝试完善改进它，使它也能够较好地和C++异常处理模型结合上）。
那么C++标准中对于这种同一个程序有不同的运行结果有何解释呢？这里需要注意的是，window2000系统下catch(…)能捕获住系统异常， 这完全是它自己的扩展。在C++标准中并没有要求到这一点，它只规定catch(…)必须能捕获程序中所有通过throw语句抛出的异常。因此上面的这个 程序在linux系统下的运行结果也完全是符合C++标准的。虽然大家也必须承认window2000系统下对C++异常处理模型的这种扩展确实是一个很 不错的完善，极大得提高了程序的安全性。
为什么要用catch(…)这个东东？
程序员朋友们也许会说，这还有问吗？这篇文章的一开始不就讲到了吗？catch(…)能够捕获多种数据类型的异常对象，所以它提供给程序员一种对异常 对象更好的控制手段，使开发的软件系统有很好的可靠性。因此一个比较有经验的程序员通常会这样组织编写它的代码模块，如下：
void Func()
{
try
{
// 这里的程序代码完成真正复杂的计算工作，这些代码在执行过程中
// 有可能抛出DataType1、DataType2和DataType3类型的异常对象。
}
catch(DataType1& d1)
{
}
catch(DataType2& d2)
{
}
catch(DataType3& d3)
{
}
// 注意上面try block中可能抛出的DataType1、DataType2和DataType3三
// 种类型的异常对象在前面都已经有对应的catch block来处理。但为什么
// 还要在最后再定义一个catch(…) block呢？这就是为了有更好的安全性和
// 可靠性，避免上面的try block抛出了其它未考虑到的异常对象时导致的程
// 序出现意外崩溃的严重后果，而且这在用VC开发的系统上更特别有效，因
// 为catch(…)能捕获系统出现的异常，而系统异常往往令程序员头痛了，现
// 在系统一般都比较复杂，而且由很多人共同开发，一不小心就会导致一个
// 指针变量指向了其它非法区域，结果意外灾难不幸发生了。catch(…)为这种
// 潜在的隐患提供了一种有效的补救措施。
catch(…)
{
}
}
还有，特别是VC程序员为了使开发的系统有更好的可靠性，往往在应用程序的入口函数中（如MFC框架的开发环境下 CXXXApp::InitInstance()）和工作线程的入口函数中加上一个顶层的trycatch块，并且使用catch(…)来捕获一切所有的 异常，如下：
BOOL CXXXApp::InitInstance()
{
if (!AfxSocketInit())
{
AfxMessageBox(IDP_SOCKETS_INIT_FAILED);
return FALSE;
}
AfxEnableControlContainer();
// Standard initialization
// If you are not using these features and wish to reduce the size
// of your final executable, you should remove from the following
// the specific initialization routines you do not need.
#ifdef _AFXDLL
Enable3dControls(); // Call this when using MFC in a shared DLL
#else
Enable3dControlsStatic(); // Call this when linking to MFC statically
#endif
// 注意这里有一个顶层的trycatch块，并且使用catch(…)来捕获一切所有的异常
try
{
CXXXDlg dlg;
m_pMainWnd = &dlg;
int nResponse = dlg.DoModal();
if (nResponse == IDOK)
{
// TODO: Place code here to handle when the dialog is
// dismissed with OK
}
else if (nResponse == IDCANCEL)
{
// TODO: Place code here to handle when the dialog is
// dismissed with Cancel
}
}
catch(…)
{
// dump出系统的一些重要信息，并通知管理员查找出现意外异常的原因。
// 同时想办法恢复系统，例如说重新启动应用程序等
}
// Since the dialog has been closed, return FALSE so that we exit the
// application, rather than start the application's message pump.
return FALSE;
}
通过上面的例程和分析可以得出，由于catch(…)能够捕获所有数据类型的异常对象，所以在恰当的地方使用catch(…)确实可以使软件系统有着更 好的可靠性。这确实是大家使用catch(…)这个东东最好的理由。但不要误会的是，在C++异常处理模型中，不只有catch(…)方法能够捕获几乎所 有类型的异常对象（也许有其它更好的方法，在下一篇文章中主人公阿愚带大家一同去探讨一下），可C++标准中为什么会想到定义这样一个catch(…) 呢？有过java或C#编程开发经验的程序员会发现，在它们的异常处理模型中，并没有这样类似的一种语法，可这里不得不再次强调的是，java中的异常处 理模型是C++中的异常处理模型的完善改进版，可它反而没有了catch(…)，为何呢？还是先去看看下一章吧，“C++的异常处理和面向对象的紧密关系 ”。也许大家能找到一个似乎合理的原因。
转自 http://hi.baidu.com/swdraven/blog/item/e50ee5268e49a21e8b82a103.html