1. 丟擲異常
1.1 丟擲異常（也稱為拋棄異常）即檢測是否產生異常，在c++中，其採用throw語句來實現，如果檢測到產生異常，則丟擲異常。
該語句的格式為： throw 表示式;
如果在try語句塊的程式段中（包括在其中呼叫的函式）發現了異常，且拋棄了該異常，則這個異常就可以被try語句塊後的某個catch語句所捕獲並處理，捕獲和處理的條件是被拋棄的異常的型別與catch語句的異常型別相匹配。由於c++使用資料型別來區分不同的異常，因此在判斷異常時，throw語句中的表示式的值就沒有實際意義，而表示式的型別就特別重要。
1.2 丟擲異常實際是作為另一種返回值來使用的。 丟擲異常的好處一是可以不干擾正常的返回值，另乙個是呼叫者必須處理異常，而不像以前c語言返回乙個整數型的錯誤碼，呼叫者往往將它忽略了。
1.3 舉例說明
假如說a方法掉呼叫-->b方法呼叫-->c方法。 然後在b和c方法裡定義了throws exception。a方法裡定義了try catch。
那麼呼叫a方法時，在執行到c方法裡出現了異常，那麼這個異常就會從c拋到b，再從b拋到a。在a裡的try catch就會捕獲這個異常，然後你就可以在catch寫自己的處理**。
那麼為什麼當時出現了異常不去處理呢？ 因為你業務邏輯呼叫的是a方法，你執行了a方法，當然要在a裡得到異常，然後來處理。如果在c裡面就處理異常，這就破壞程式結構了。 另外，a呼叫了c方法，假如還接著也呼叫了d,e,f方法，假如他們都有可能丟擲異常，你說是在a裡面獲得處理一次好，還是在c,d,e,f得到了異常，每個都當時處理一下的好？ 當時就處理異常理論上也是可以的，而且大多數時候，到底在哪處理異常，是要根據需求和專案的具體情況的。
2. 建構函式可以丟擲異常。
3. c++標準指明析構函式不能、也不應該丟擲異常。
c++異常處理模型是為c++語言量身設計的，更進一步的說，它實際上也是為c++語言中物件導向而服務的。c++異常處理模型最大的特點和優勢就是對c++中的物件導向提供了最強大的無縫支援。那麼如果物件在執行期間出現了異常，c++異常處理模型有責任清除那些由於出現異常所導致的已經失效了的物件(也即物件超出了它原來的作用域)，並釋放物件原來所分配的資源， 這就是呼叫這些物件的析構函式來完成釋放資源的任務，所以從這個意義上說，析構函式已經變成了異常處理的一部分。
上面的論述c++異常處理模型它其實是有乙個前提假設——析構函式中是不應該再有異常丟擲的。試想，如果物件出了異常，現在異常處理模組為了維護系統物件資料的一致性，避免資源洩漏，有責任釋放這個物件的資源，呼叫物件的析構函式，可現在假如析構過程又再出現異常，那麼請問由誰來保證這個物件的資源釋放呢?而且這新出現的異常又由誰來處理呢?不要忘記前面的乙個異常目前都還沒有處理結束，因此這就陷入了乙個矛盾之中，或者說無限的遞迴巢狀之中。所以c++標準就做出了這種假設，當然這種假設也是完全合理的，在物件的構造過程中，或許由於系統資源有限而致使物件需要的資源無法得到滿足，從而導致異常的出現，但析構函式完全是可以做得到避免異常的發生，畢竟你是在釋放資源呀!
假如無法保證在析構函式中不發生異常，怎麼辦? 雖然c++標準中假定了析構函式中不應該，也不永許丟擲異常的。但實際的軟體系統開發中是很難保證到這一點的。所有的析構函式的執行過程完全不發生一點異常，這根本就是天方夜譚，或者說自己欺騙自己算了。而且有時候析構乙個物件(釋放資源)比構造乙個物件還更容易發生異常，例如乙個表示引用記數的控制代碼不小心出錯， 結果導致資源重複釋放而發生異常，當然這種錯誤大多時候是由於程式設計師所設計的演算法在邏輯上有些小問題所導致的，但不要忘記現在的系統非常複雜，不可能保證 所有的程式設計師寫出的程式完全沒有bug。因此杜絕在析構函式中決不發生任何異常的這種保證確實是有點理想化了。
3.1 more effective c++提出兩點理由（析構函式不能丟擲異常的理由）：
1）如果析構函式丟擲異常，則異常點之後的程式不會執行，如果析構函式在異常點之後執行了某些必要的動作比如釋放某些資源，則這些動作不會執行，會造成諸如資源洩漏的問題。
2）通常異常發生時，c++的機制會呼叫已經構造物件的析構函式來釋放資源，此時若析構函式本身也丟擲異常，則前乙個異常尚未處理，又有新的異常，會造成程式崩潰的問題。
3.2 那麼當無法保證在析構函式中不發生異常時， 該怎麼辦?
其實還是有很好辦法來解決的。那就是把異常完全封裝在析構函式內部，決不讓異常丟擲函式之外。這是一種非常簡單，也非常有效的方法。
~classname()
catch() }
3.3 析構函式中丟擲異常時概括性總結
1）c++中析構函式的執行不應該丟擲異常；
2）假如析構函式中丟擲了異常，那麼你的系統將變得非常危險，也許很長時間什麼錯誤也不會發生；但也許你的系統有時就會莫名奇妙地崩潰而退出了，而且什麼跡象也沒有，崩得你滿地找牙也很難發現問題究竟出現在什麼地方；
3）當在某乙個析構函式中會有一些可能（哪怕是一點點可能）發生異常時，那麼就必須要把這種可能發生的異常完全封裝在析構函式內部，決不能讓它丟擲函式之外（這招簡直是絕殺！呵呵！）；
4）一定要切記上面這幾條總結，析構函式中丟擲異常導致程式不明原因的崩潰是許多系統的致命內傷！
為什麼建構函式和析構函式中不應該呼叫虛函式
在語法上，構造函式呼叫虛函式當然是沒有問題的。但是這種用法不一定能得到想要的結果，還會引發一些小問題。class base virtual void func1 virtual void func2 class derived public base virtual void func1 virtu...
為什麼析構函式中不能丟擲異常？
c 異常處理模型是為c 語言量身設計的，更進一步的說，它實際上也是為c 語言中物件導向而服務的。c 異常處理模型最大的特點和優勢就是對c 中的物件導向提供了最強大的無縫支援。那麼如果物件在執行期間出現了異常，c 異常處理模型有責任清除那些由於出現異常所導致的已經失效了的物件 也即物件超出了它原來的作...
關於基類的析構函式應不應該為virtual
如果該基類要派生其它類，則一定要 virtual 基類 coperation 的析構函式沒加 virtual 時程式執行結果 可以看到加運算類沒有被析構。為什麼因為工廠類的成員型別為基類指標，它只析構了基類。基類 coperation 的析構函式加 virtual 時程式執行結果 可以看到所有構造的...