Vc具有极其强的______，是很好的_______。Vc在______条件下极稳定。
在__excep后面的()中是一个表达式，值可以是:
EXCEPTION_CONTINUE_EXECUTION (–1) 异常被忽略，控制流将在异常出现的点之后，继续恢复运行。
EXCEPTION_CONTINUE_SEARCH (0) 异常不被识别，也即当前的这个__except模块不是这个异常错误所对应的正确的异常处理模块。系统将继续到上一层的try-except域中继续查找一个恰当的__except模块。
EXCEPTION_EXECUTE_HANDLER (1) 异常已经被识别，也即当前的这个异常错误，系统已经找到了并能够确认，这个__except模块就是正确的异常处理模块。控制流将进入到__except模块中。
c++ 异常处理
__try//去掉前面的下划
{
CreateProcessA("c:\\windows\\system32\\notepad.exe", NULL, NULL, NULL, false, 0, NULL, NULL, NULL, NULL);
}
__except(EXCEPTION_EXECUTE_HANDLER)//将此段注释掉,并将下面的catch段全部恢复
{
MessageBoxA(0, "CMemoryException", 0, 0);
}
//catch (CMemoryException* e)
//{
////e->GetErrorMessage()
//MessageBoxA(0, "CMemoryException", 0, 0);
//}
//catch (CFileException* e)
//{
//MessageBoxA(0, "CFileException", 0, 0);
//}
//catch (CException* e)
//{
//MessageBoxA(0, "CException", 0, 0);
//}
你可以将__try,__except改成try catch试试。
说点基本知识：
在debug版本中try catch是可行的，当然也有不行的时候，这里是相对来说
但在release版本编译器没有找到throw代码， 他就会认为try catch结构是多余的， 给优化掉
需要使用__try, __except.
但是用__try, __except块还有问题， 就是这个不是C++标准， 而是Windows平台特有的扩展。 而且如果在使用过程中涉及局部对象析构函数的调用，则会出现C2712 的编译错误。 那么还有没有别的办法呢？
有， 就是仍然使用C++标准的try{}catch(..){}， 但在编译命令行中加入 /EHa 的参数。这样VC编译器不会把try catch模块给优化掉了。
=====补充下====
如果单纯从回答问题的角度来讲，是讨论try catch的用法。
但从问题本身的意义来讲，是为了避免出错，及快速定位问题。
所以从避免出错，以及快速定位来讲，使用try catch是很苍白的。
就快速定位来讲：try catch使用就麻烦了，且也不直接。
我这里有多种方案来快速定位：
前提定义一套输出到log文件的函数
1.每个不保险的函数中增加一个块,
AA()//设其不保险
{
#ifdef _DEBUG
//这里调用你那一套输出log文件,当然并非一定要用log文件，也可以用直接输出信息，
//这个根据情况，当然你也可以把#ifdef块写到你定义的输出函数中。
#endif
}
2.根据输出信息来看执行到哪了，因为程序挂住了，程序后面的信息就输出不了，所以你就找最后一条输出的下一个函数。
最后补充：其实没有什么好的机制来快速定位错误，当然拦截错误为用户提供友好界面就另外一回事。
因为有好的机制你实现起来略显麻烦，不管多大的项目，都有常用代码，大部分是经验。
哎还没说完，有事要出去了，不过这些应该能让你明白意思
