當今用于例外（Itanium ABI，VC ++ 64位）的主要模型是零成本模型例外。

這樣做的想法是，編譯器將生成一個邊表，該邊表將可能引發異常的任何點（程序計數器）映射到處理程序列表，而不是通過設置防護程序并在所有地方明確檢查是否存在異常來浪費時間。引發異常時，將查詢此列表以選擇正確的處理程序（如果有），并取消堆棧堆棧。

與典型if (error)策略相比：

顧名思義，零成本模型在沒有異常發生時是免費的

if發生異常時，費用約為10倍/ 20倍

然而，成本并不是微不足道的：

邊桌通常很冷，因此從內存中獲取它要花費很長時間

確定正確的處理程序涉及到RTTI：要提取的許多RTTI描述符，分散在內存中以及要運行的復雜操作（基本上是dynamic_cast對每個處理程序的測試）

因此，大多數緩存未命中，因此與純CPU代碼相比并不容易。

注意：有關更多詳細信息，請閱讀TR18015報告的第5.4節異常處理（pdf）

因此，是的，異常路徑在異常路徑上速度較慢，但與其他方式相比，它們通常比顯式檢查（if策略）更快。

注意：安德烈·亞歷山德列斯庫（Andrei Alexandrescu）似乎質疑這種“快速”。我個人已經看到事情發生了雙向變化，有些程序在例外情況下運行得更快，而在分支程序中運行得更快，因此在某些情況下確實確實缺乏優化性。

有關系嗎 ？

我會聲稱沒有。編寫程序時應考慮可讀性，而不要考慮性能（至少，不作為首要標準）。當人們期望調用者無法或不希望當場處理失敗并將失敗傳遞到堆棧時，將使用異常。獎勵：在C ++ 11中，可以使用標準庫在線程之間封送異常。

不過，這很微妙，我聲稱map::find不應拋出，但是如果嘗試取消引用失敗，因為它為null，那么我可以map::find返回一個checked_ptrwhich拋出異常：在后一種情況下，就像Alexandrescu引入的類一樣，調用者選擇在顯式檢查和依賴異常之間。在不給呼叫者更多責任的情況下授權呼叫者通常是良好設計的標志。

這取決于編譯器。

例如，GCC以處理異常時的性能很差而著稱，但是在過去幾年中，這種情況變得更好了。

但是請注意，處理異常（顧名思義）應該是異常，而不是軟件設計中的規則。當您的應用程序每秒拋出如此多的異常以至于影響性能并且仍然被認為是正常操作時，您應該寧愿以不同的方式去做。

異常是通過消除所有笨拙的錯誤處理代碼來提高代碼可讀性的好方法，但是一旦它們成為常規程序流程的一部分，它們就會變得很難遵循。請記住，a throw幾乎是goto catch偽裝的。