函數簽名中“Throw”的危險

雖然在函數簽名中加入“throw”關鍵字可能很誘人明確聲明潛在的例外情況，強烈建議不要這樣做。儘管其目的看似簡單，但有幾個技術原因導致這種方法被認為是一個糟糕的選擇。

編譯器限制

編譯器無法強制執行會產生一個重大問題函式簽章中宣告的例外規格。因此，編譯器無法驗證函數是否確實會拋出指定的異常。這會導致潛在的誤導性簽名，因為該函數實際上可能會拋出不同的異常或根本不拋出任何異常。

運行時無效

在運行時檢查異常規範，強加性能開銷。與在編譯時更有效地執行這些檢查的現代異常處理機制相比，這是特別不可取的。

不一致的實作

異常規範在不同的環境中具有不同層級的支援編譯器。例如，MSVC 在很大程度上忽略了異常規範，除了「throw()」這種特殊情況，它被解釋為保證不會拋出例外。這種不一致會造成特定於平台的問題並使可移植性變得複雜。

異常規範的替代方案

考慮到在函數簽章中使用「throw」的缺點，建議採用異常處理的替代方法。其中包括：

• 使用RAII（資源獲取即初始化）技術來管理資源和處理潛在錯誤
• 使用異常類別來明確定義和處理特定的異常場景
• 使用結構化異常處理機制提供編譯時檢查和更有效率的異常處理