條款15：了解異常處理的系統開銷
為了在運行時處理異常，程序要記錄大量的信息。無論執行到什么地方，程序都必須能夠識別出如果在此處拋出異常的話，將要被釋放哪一個對象；程序必須知道每一個入口點，以便從try塊中退出；對于每一個try塊，他們都必須跟蹤與其相關的catch子句以及這些catch子句能夠捕獲的異常類型。這種信息的記錄不是沒有代價的。確保程序滿足異常規格不需要運行時的比較（runtime comparisons），而且當異常被拋出時也不用額外的開銷來釋放相關的對象和匹配正確的catch字句。但是異常處理確是有代價的，即使你沒有使用try，throw或catch關鍵字，你同樣得付出一些代價。
讓我們先從你不使用任何異常處理特性也要付出的代價談起。你需要空間建立數據結構來跟蹤對象是否被完全構造（constructed）(參加條款10)，你也需要系統時間保持這些數據結構不斷更新。這些開銷一般不是很大，但是當采用不支持異常的方法編譯的程序一般比支持異常的程序運行速度更快所占空間也更小。
在理論上，你不能對此進行選擇：C++編譯器必須支持異常，也就是說，當你不用異常處理時你不能讓編譯器生產商消除這方面的開銷，因為程序一般由多個獨立生成的目標文件（object files）組成，只有一個目標文件不進行異常處理并不能代表其他目標文件不進行異常處理。而且即使組成可執行文件的目標文件都不進行異常處理，那么還有它們所連接的程序庫呢？如果程序的任何部分使用了異常，其它部分必須也支持異常。否則在運行時程序就不可能提供正確的異常處理。
不過這只是理論，實際上大部分支持異常的編譯器生產商都允許你自由控制是否在生成的代碼里包含進支持異常的內容。如果你知道你程序的任何部分都不使用try，throw或catch，并且你也知道所連接的程序庫也沒有使用try，throw或catch，你就可以采用不支持異常處理的方法進行編譯，這可以縮小程序的尺寸和提高速度，否則你就得為一個不需要的特性而付出代價。隨著時間的推移，使用異處理的程序庫開始變得普遍了，上面這種方法將逐漸不能使用，但是根據目前的軟件開發情況來看，如果你已經決定不使用任何的異常特性，那么采用不支持異常的方法編譯程序是一個性能優化的合理方法。同樣這對于想避開異常的程序庫來說也是一個性能優化的好方法，這能保證異常不會從客戶端程序傳遞進程序庫里，不過同時這樣做也會妨礙客戶端程序重定義程序庫中聲明的虛擬函數，并不允許有在客戶端定義的回調函數。
使用異常處理的第二個開銷來自于try塊，無論何時使用它，也就是無論何時你想能夠捕獲異常，那你都得為此付出代價。不同的編譯器實現try塊的方法不同，所以編譯器與編譯器間的開銷也不一樣。粗略地估計，如果你使用try塊，代碼的尺寸將增加5％－10％并且運行速度也同比例減慢。這還是假設程序沒有拋出異常，我這里討論的只是在程序里使用try塊的開銷。為了減少開銷，你應該避免使用無用的try塊。
編譯器為異常規格生成的代碼與它們為try塊生成的代碼一樣多，所以一個異常規格一般花掉與try塊一樣多的系統開銷。什么？你說你認為異常規格只是一個規格而已，你認為它們不會產生代碼？那么好，現在你應該對此有新的認識了。
現在我們來到了問題的核心部分，看看拋出異常的開銷。事實上我們不用太關心這個問題，因為異常是很少見的，這種事件的發生往往被描述為exceptional（異常的，罕見的）。80－20規則（參見條款16）告訴我們這樣的事件不會對整個程序的性能造成太大的影響。但是我知道你仍舊好奇地想知道如果拋出一個異常到底會有多大的開銷，答案是這可能會比較大。與一個正常的函數返回相比，通過拋出異常從函數里返回可能會慢三個數量級。這個開銷很大。但是僅僅當你拋出異常時才會有這個開銷，一般不會發生。但是如果你用異常表示一個比較普遍的狀況，例如完成對數據結構的遍歷或結束一個循環，那你必須重新予以考慮。