避免切片異常類型（C++）

Question

我正在爲我的庫設計C++的異常層次結構。 「層次結構」是派生自std :: runtime_error的4個類。我想避免slicing problem的異常類，使複製構造函數受到保護。但顯然gcc需要在拋出它們的實例時調用拷貝構造函數，因此抱怨受保護的拷貝構造函數。 Visual C++ 8.0編譯相同的代碼很好。是否有任何可移植的方法來緩解異常類的切片問題？該標準是否說明了某個實現是否可能需要要拋出的類的拷貝構造函數？

Answer 1

我會避免設計一個不同於您的庫的異常層次結構。儘可能使用std::exception層次結構，總是從該層次結構中的某些內容中派生出您的異常。您可能需要特別閱讀exceptions portion of Marshall Cline's C++ FAQ - 讀取FAQ 17.6,17.9,17.10和17.12。

至於「強制用戶參考搭上」，我不知道這樣做的一個很好的方式。我已經在一個小時內拿出左右的打（這是週日下午）的唯一途徑是基於polymorphic throwing：

class foo_exception { 
public: 
    explicit foo_exception(std::string msg_): m_msg(msg_) {} 
    virtual ~foo_exception() {} 
    virtual void raise() { throw *this; } 
    virtual std::string const& msg() const { return m_msg; } 
protected: 
    foo_exception(foo_exception const& other): m_msg(other.m_msg) {} 
private: 
    std::string m_msg; 
}; 

class bar_exception: public foo_exception { 
public: 
    explicit bar_exception(std::string msg_): 
     foo_exception(msg_), m_error_number(errno) {} 
    virtual void raise() { throw *this; } 
    int error_number() const { return m_error_number; } 
protected: 
    bar_exception(bar_exception const& other): 
     foo_exception(other), m_error_number(other.m_error_number) {} 
private: 
    int m_error_number; 
}; 

的想法是讓拷貝構造函數保護，強制用戶撥打Class(args).raise()代替的throw Class(args)。這可以讓你拋出一個多態的綁定異常，用戶只能通過引用來捕獲異常。任何企圖通過值捕獲的應該是都會有一個很好的編譯器警告。喜歡的東西：

foo.cpp:59: error: ‘bar_exception::bar_exception(const bar_exception&)’ is protected

foo.cpp:103: error: within this context

當然這一切是有代價的，因爲你可以不再使用throw明示或您將看到一個類似的編譯器警告打招呼：

foo.cpp: In function ‘void h()’:

foo.cpp:31: error: ‘foo_exception::foo_exception(const foo_exception&)’ is protected

foo.cpp:93: error: within this context

foo.cpp:31: error: ‘foo_exception::foo_exception(const foo_exception&)’ is protected

foo.cpp:93: error: within this context

總之，我會依靠編碼標準和文件說明你應該總是引用。確保您的庫捕獲通過引用處理的異常並拋出新對象（例如，throw Class(constructorArgs)或throw;）。我希望其他C++程序員能夠擁有相同的知識 - 但爲了確保可以在任何文檔中添加註釋。

Answer 2

你的異常需要有一個公共的拷貝構造函數。編譯器必須能夠複製它以便異常處理工作。

你的問題的解決方案是總是通過引用而不是追趕：

try { 
    // some code... 
    throw MyException("lp0 is on fire!"); 
} catch (MyException const &ex) { 
    // handle exception 
} 

（const -ness是可選的，但我一直把它放在因爲有很少需要修改的異常對象。）

Answer 3

托馬斯的回答是正確的，但我也想建議你不要「設計一個異常層次結構」來浪費你的時間。設計類層次結構是一個非常糟糕的想法，尤其是當您可以簡單地從C++ Standard異常類中派生一對（並且不超過）新的異常類型時。

Answer 4

我會說不使用任何內置的C++異常代碼。如果你必須有例外，從頭開始創建你自己的。這是確保他們的行爲類似的唯一方法，更不用說以類似的方式實施了，並且直言不諱地在C++中實現異常是無能的。

Answer 5

我已經找到阻止我庫的客戶從值不正確，捕獲異常的兩個便攜式的方式從內部異常類virtual raise方法

1. 拋出異常，並進行拷貝構造函數的保護。 （謝謝D.Shawley）
2. 從庫中拋出派生異常併爲客戶端發佈異常基類。基類可以擁有受保護的拷貝構造函數，這隻允許捕獲它們的好方法。 （提到here爲相似的問題）

C++標準確實表明複製構造函數需要在throw點可訪問。我的配置中的Visual C++ 8.0違反了這部分標準，因爲沒有強制執行複製構造函數。在第15.1.3：

A throw-expression initializes a temporary object, the type of which is determined by removing any top-level cv-qualifiers from the static type of the operand of throw and adjusting the type from 「array of T」 or 「function returning T」 to 「pointer to T」 or 「pointer to function returning T」, respectively.

If the use of the temporary object can be eliminated without changing the meaning of the program except for the execution of constructors and destructors associated with the use of the temporary object (12.2), then the exception in the handler can be initialized directly with the argument of the throw expression. When the thrown object is a class object, and the copy constructor used to initialize the temporary copy is not accessible, the program is ill-formed (even when the temporary object could otherwise be eliminated)

^{這個答案被張貼到OP的問題，我從問題刪除，並張貼作爲一個單獨的答案。}