為了在運行時處理異常，程序要記錄大量的信息。無論執行到什麼地方，程序都必須能夠識別出如果在此處拋出異常的話，將要被釋放哪一個對象;程序必須知道每一個入口點，以便從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塊生成的代碼一樣多，所以一個異常規格一般花掉與tyr塊一樣多的系統開銷。什麼?你說你認為異常規格只是一個規格而已，你認為它們不會產生代碼?那麼好，現在你應該對此有新的認識了。
現在我們來到了問題的核心部分，看看拋出異常的開銷。事實上我們不用太關心這個問題，因為異常是很少見的，這種事件的發生往往被描述為exceptional(異常的，罕見的)。80-20規則(參見條款16)告訴我們這樣的事件不會對整個程序的性能造成太大的影響。但是我知道你仍舊好奇地想知道如果拋出一個異常到底會有多大的開銷，答案是這可能會比較大。與一個正常的函數返回相比，通過拋出異常從函數裡返回可能會慢三個數量級。這個開銷很大。但是僅僅當你拋出異常時才會有這個開銷，一般不會發生。但是如果你用異常表示一個比較普遍的狀況，例如完成對數據結構的遍歷或結束一個循環，那你必須重新予以考慮。
不過請等一下，你問我是怎麼知道這些事情的呢?如果說支持異常對於大多數編譯器來說是一個較新的特性，如果說不同的編譯器異常方法也不同，那麼我如何能說程序的尺寸將增大5%-10%，它的速度也同比例減慢，而且如果有大量的異常被拋出，程序運行速度會呈數量級的減慢呢?答案是令人驚恐的:一些傳聞和一些基准測試(benchmarks)(參見條款23)。事實是大部分人包括編譯器生產商在異常處理方面幾乎沒有什麼經驗，所以盡管我們知道異常確實會帶來開銷，卻很難預測出開銷的准確數量。
謹慎的方法是對本條款所敘述的開銷有了解，但是不深究具體的數量。(即定性不定量 譯者注)不論異常處理的開銷有多大我們都得堅持只有必須付出時才付出的原則。為了使你的異常開銷最小化，只要可能盡量就采用不支持異常的方法編譯程序，把使用try塊和異常規格限制在你確實需要它們的地方，並且只有在確為異常的情況下(exceptional)才拋出異常。如果你在性能上仍舊有問題，總體評估一下你的軟件以決定異常支持是否是一個起作用的因素。如果是，那就考慮選擇其它的編譯器，能在C++異常處理方面具有更高實現效率的編譯器。
