學習code：

 argv[])

{
  try...{
... ...
  }
  catch(std::exception& e) ...{
    std::cerr <<"Exception caughted:"<< std::endl
      << e.what ()
      << std::endl;
  }
  catch(...) ...{
    std::cerr <<"Exception caughted:"<< std::endl
      <<

"unknown exception caughted."
      << std::endl;
  }

  return0;
}

蒐集的解釋：

try和catch必須成對出現，都是由程式設計師自已來處理異常，不過在IDE環境下都是先響應系統異常處理，再響應使用者異常處理。脫離IDE環境，讓程式單獨執行，就只響應使用者異常處理__try是用在C中，try是用在C++中。

  try  
      程式程式碼  
   
  catch（錯誤型別1）  
        //如果出錯，錯誤型別位catch引數中的錯誤型別，執行此段程式  
  catch（錯誤型別2）  
        //如果出錯，錯誤型別位catch引數中的錯誤型別，執行此段程式  
  end   try  

在C++ 中使用異常處理，一般情況下是在你讓為可能出現錯誤的地方，用try塊將其包含在其中，以便捕獲異常。但是也不能在程式設計中過度的使用異常處理。下面是一些不使用異常的原則：
1、不要在非同步事件中使用異常。
2、不要在處理簡單錯誤的時候使用異常。
3、不要將異常用於程式的流程控制。
4、不要強迫自己使用異常。

關於異常的advice，我來小小翻譯一下：《C++ Pragramming Language》
1。使用異常作為“出錯”處理2。如果local的控制流本身就可以處理，那就不要使用異常，因為異常是處理不同單元之間訊息傳遞的機制。
3。在使用異常的程式碼中，使用“資源分配即初始化”的技術來管理資源。比如將資源申請放入某個代理類的初始化中，將資源釋放放入代理類的析構中，然後用這個代理來管理資源
4。不是所有的程式都需要是異常安全的。資源可以不被主動釋放，比如你可以放心的將記憶體資源的釋放交給作業系統（通過abort等）
5。可以使用“資源分配即初始化”的技術和異常處理來保持不變性。比如：保證異常發生前後環境不變，對於local變數可以通過代理釋放資源，對於local以外的變數可以在catch後的異常處理中將內容恢復。
6。最小化try塊的使用（能不用就不用）。不要在異常處理中釋放資源，應使用“資源分配即初始化”的技術。
7。不是每個函式都需要處理所有的錯誤。
8。在建構函式中，丟擲異常來暗示資源分配失敗。這比建構函式設定一種失敗的狀態要好得多，清晰的多。
9。除非已經出現不可恢復的問題，不要在拷貝建構函式中丟擲異常。因為拷貝建構函式通常涉及到兩個操作：釋放預設資源，獲取新的資源。如果丟擲異常，就很難恢復到拷貝構造前的狀態。
10。不要在解構函式中丟擲異常
11。在Main（）函式中撲獲所有異常
12。普通的程式碼和異常處理的程式碼不要耦合在一起。
13。確保建構函式獲取的資源在解構函式裡被釋放
14。保持資源管理的結構層次。即不同層次的資源的獲取和釋放不要相互干涉。
15。使用”異常規範“作為主要的介面。即將模組的異常規範以介面的形式提供給模組的使用者，這也可以提高異常處理的效率和命中率。
16。要意識到，由new分配的記憶體不會在異常處理中釋放掉。
17。如果一個程式可能丟擲異常也可能不丟擲，在使用這個程式時，最好是假設他會丟擲異常（必要在不同模組之間產生不必要的耦合關係）
18。不是所有異常都繼承自類exception
19。作為一個函式庫，在出錯的時候不應該一廂情願的將程式關掉，而是應該通過丟擲異常，將出錯訊息傳達給他的使用者。異常正是在不同模組之間傳遞出錯訊息的很好的機制。
20。作為一個函式庫，他不應該將出錯診斷資訊顯示在IO裝置上，比如stderr，他不應該對使用者使用的裝置作假定（或許，使用者已經把stderr關掉了，或是根本就沒有標準的顯示終端），而應該是通過異常機制。
21。在設計階段早期就安排好出錯處理的策略。

如果有認識不妥的地方，大家一起來討論一下。