看看下面這個簡單例子：
#include <memory>
#include <iostream>
using namespace std;
class BaseClass
{
public:
    BaseClass(){};
    ~BaseClass()
    {
        throw runtime_error("example runtime error.");
    };
};
 
int main(int *argc , char **argv)
{
    BaseClass *pBase = new BaseClass;
    delete pBase;
    return 0;
}
 
在VS2008下調用teminate時候還會調用abort，這個程序會非正常結束，如果在main函數中試圖這樣做：
int main(int *argc , char **argv)
{
    BaseClass *pBase = new BaseClass;
    try
    {
        delete pBase;
    }
    catch(runtime_error &err)
    {
        cout<<err.what()<<endl;
    }
    return 0;
}
 
結果會跟上面一樣（非正常結束），因為delete是不會將任何異常傳遞到其外面的；一種比較折中的解決方法是，當destructor中存在異常拋出時，在destructor最后添加一個能捕獲所有異常的catch處理塊，catch處理塊又什么工作都不做，如下：
 
~BaseClass()
{
    try
    {
        throw runtime_error("error in destructor");
    }
    catch(...)
    {
    }
};
看起來是一種很壞很無奈的辦法，但正如Scott Meyers在《effective c++》中所說：
“一般而言，將異常吞掉是個壞主意，因為它壓制了"某些動作失敗"的重要信息!然而有時候吞下異常也比負擔"草率結束程序"或"不明確行為帶來的風險好”。
 
 
后記
對于很多exception handling的概念性細節（比如何時使用引用類型的異常捕捉、異常捕獲層次的類型轉換等等）我沒做任何闡述，可以去看看《C++ PRIMER》的第十七章，有著很想盡的講解。。。 對于MS編譯器對異常規范的不支持，我很難理解，因為G++編譯器確實是支持的。之前在討論C++的object布局時（點擊這里）也曾感嘆MS的編譯器在優化方面沒G++走得快，對于這些，或許是我運氣不好，老是碰到MS不如G++的地方，也或許是我現在幾乎不用G++編譯器的而體會不到其不如MS編譯器的地方的緣故吧。。。exception handling的確能為提高代碼質量的改善作出或多說少的貢獻，但華麗麗的外表下，因為用不好它而導致的程序的很多不明確（如teminate當前程序）和不正常（如資源泄露）行為也是令人比較頭大的地方。貌似只有多熟用有技巧性的用是唯一能解決所有問題的方法了。。