關於異常的雙重破壞需要說明的對象

Question

在他的精闢論文，
Error and Exception Handling，
@Dave Abrahams說：

讓你的異常類免疫雙重毀滅如果可能的話 。不幸的是，一些流行的編譯器偶爾會導致異常對象被銷燬兩次。如果你可以安排它是無害的（例如通過歸零刪除的指針），你的代碼將更加健壯。

我無法理解這個特殊的方針，有人可以：

1. 請提供此雙重破壞場景&
2. 什麼是實現一個自定義異常類的最佳方法的代碼示例避免這種情況？

Answer 1

像@託尼說，這個指導原則是爲了防止編譯器錯誤。這個指南可以追溯到2001年左右，當時例外支持可能還是有點不穩定。從那以後，我認爲/希望大多數編譯器已經修復了這個錯誤，所以指南可能不再相關。

FWIW，該指南已從the CERT coding practices中刪除。在這個頁面的討論中，提出了一個有趣的觀點：無論如何都是UB破壞對象，所以無論你在類中如何處理它都不會使你的程序完全可預測。然而，如果你真的希望你的代碼在編譯器（包括舊版本）中可移植，你應該考慮所有這些小故障。例如，Boost經歷了許多工作才能解決編譯器bug;他們可以簡單地編寫符合標準的代碼，並將失敗的責任推遲到實現，但這會阻礙他們的庫的採用。

編寫代碼時是否需要謹慎取決於您的要求，基本上歸結爲這個問題：是否支持幾十個編譯器真的值得您需要的工作量？

Answer 2

要通過@chrisaycock從文章引述：

「爲什麼兩次毀滅」？由於編譯器錯誤，這就是爲什麼！這是一個 錯誤，編譯器不應該這樣做。但他們這樣做。我在一個 項目上工作，在這個項目中，我使用Sun的Studio8編譯器啃過這個項目。 I 在一個catch子句中創建了一個ostringstream對象，並且發現它遭到了兩次破壞 。爲了解決它，我把它移到了嘗試之前，然後它工作。這種錯誤不會經常發生。在catch子句中創建對象的大部分時間是 都可以，但它是 意識到的東西。

問候，

安德魯·馬洛

Answer 3

有一個在標準中沒有的場景，其中一個對象可能被破壞的兩倍。發生這種情況的任何實例都是代表用戶的錯誤，或者，如果對象被編譯器破壞（例如異常），那麼編譯器錯誤。在任何主流編譯器之前，我從來沒有聽說過這樣的錯誤，並且沒有理由相信對於編寫C++代碼的任何人來說這會有問題。