64,637
社区成员
发帖
与我相关
我的任务
分享
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 proce
ssing progamming。在介绍unix和linux下如何编程的书籍中,都会有对信号处
理编程详细的介绍,当然执著的主人公阿愚肯定对它也不会放过,会深 入到unix
沿袭下来的信号处理编程内部的实现机制,并尝试完善改进它,使它也能够较好地
和C++异常处理模型结合上)。
那么C++标准中对于这种同一个程序有不同的运行结果有何解释呢?这里需要注意
的是,window2000系统下catch(…)能捕获住系统异常, 这完全是它自己的扩展。
在C++标准中并没有要求到这一点,它只规定catch(…)必须能捕获程序中所有通过
throw语句抛出的异常。因
此上面的这个 程序在linux系统下的运行结果也完全是符合C++标准的。虽然大家
也必须承认window2000系统下对C++异常处理模型的这种扩展确实是一个很 不错的
完善,极大得提高了程序的安全性。
try
{
// 这是 mysql++ 执行数据库操作
res = query.store(email);
}
catch (const Exception& er)
{
cout << er.what();
return;
}
catch(...)
{
cout << "未知异常" << endl;
}