我應該從std :: exception繼承嗎？

Question

我見過至少有一個可靠的源代碼（我使用的一個C++類）推薦C++中應用程序特定的異常類應該從std::exception繼承。我不清楚這種方法的好處。

在C＃中，從ApplicationException繼承的原因很明顯：您會得到一些有用的方法，屬性和構造函數，只需添加或覆蓋需要的內容即可。與std::exception似乎你得到的是一個what()方法來覆蓋，你可以創建自己。

那麼使用std::exception作爲我的特定於應用程序的異常類的基類有什麼好處？是否有任何理由不從std::exception繼承？

Answer 1

最主要的好處是，使用你的類的代碼並不需要知道你的確切類型throw它，但可以只是catch的std::exception。

編輯：馬丁等人指出的那樣，你真正想要從<stdexcept>頭部聲明的std::exception子類的一個派生。

Answer 2

爲什麼你可能想從std::exception繼承的原因是因爲它可以讓你把那根據該類捕獲的異常，即：

class myException : public std::exception { ... }; 
try { 
    ... 
    throw myException(); 
} 
catch (std::exception &theException) { 
    ... 
} 

Answer 3

Difference: std::runtime_error vs std::exception()

無論您應該從它繼承還是不由你決定。標準std::exception及其標準後代提出了一種可能的異常分層結構（劃分爲logic_error子層次和runtime_error子層次結構）和一個可能的異常對象接口。如果你喜歡它 - 使用它。如果由於某種原因你需要不同的東西 - 定義你自己的異常框架。

Answer 4

如果您所有可能的例外都來自std::exception，您的catch塊可以簡單地catch(std::exception & e)，並確保捕獲所有內容。

捕獲到異常後，您可以使用該方法獲取更多信息。 C++不支持鴨子輸入，所以另一個帶what方法的類將需要不同的catch和不同的代碼來使用它。

Answer 5

從std::exception繼承的原因是它是例外的「標準」基類，所以對於團隊中的其他人員來說，例如期望基類std::exception是自然的。

如果您正在尋找方便，您可以繼承std::runtime_error，它提供std::string構造函數。

Answer 6

由於語言已經拋出std :: exception，因此無論如何您都需要抓住它來提供體面的錯誤報告。你也可以用同樣的方法來處理你自己的所有意想不到的例外情況。此外，幾乎所有拋出異常的庫都會從std :: exception中派生出它們。

換句話說，它要麼

catch (...) {cout << "Unknown exception"; } 

或

catch (const std::exception &e) { cout << "unexpected exception " << e.what();} 

而第二個選項是肯定更好。

Answer 7

有一個遺留問題，你應該知道的是對象切片。當您編寫throw e;時，throw-expression將初始化一個名爲異常對象的臨時對象，該對象的類型是通過從throw的操作數的靜態類型中除去任何頂級cv限定符來確定的。這可能不是你所期待的。問題的例子，你可以找到here。

這不是反對繼承的論點，它只是「必須知道」的信息。

Answer 8

您應該從boost::exception繼承。它提供了許多更多功能和更好理解的方式來攜帶更多數據......當然，如果您不使用Boost，那麼請忽略此建議。

Answer 9

std::exception的問題在於沒有接受消息的構造函數（在標準兼容版本中）。

因此我更喜歡從std::runtime_error派生。這源於std::exception，但其構造函數允許您將C字符串或std::string傳遞給將返回的構造函數（作爲char const*），當調用what()時。

Answer 10

我曾經參與過一個大型代碼庫的清理工作，在這個代碼庫中，前面的作者拋出了整數，HRESULTS，std :: string，char *，隨機類......各處不同的東西;只是命名一個類型，它可能被扔在某個地方。根本沒有共同的基礎課程。相信我，一旦我們認識到所有拋出的類型都有一個共同的基礎，我們可以捕獲並知道什麼都不會過去，那麼事情就會變得更加整潔。所以請你自己（以及那些將來需要維護你的代碼的人）幫忙，並且從一開始就這樣做。

Answer 11

是的，你應該從std::exception派生。

其他人已經回答說，std::exception有問題，您無法將文本消息傳遞給它，但通常不是在投擲點嘗試格式化用戶消息的好主意。相反，使用異常對象將所有相關信息傳輸到catch站點，然後可以格式化用戶友好的消息。

Answer 12

是否從任何標準異常類型派生是第一個問題。這樣做可以爲所有標準庫異常和您自己的異常處理程序啓用一個異常處理程序，但它也鼓勵這種全部處理程序。問題是人們應該只捕捉一個人知道如何處理的異常。例如，在main（）中，如果在退出之前將what（）字符串記錄爲最後的手段，那麼捕獲所有std :: exceptions可能是件好事。但是，在其他地方，這不太可能是一個好主意。

一旦您決定是否從標準異常類型派生，那麼問題是應該以哪個爲基礎。如果您的應用程序不需要i18​​n，您可能會認爲在呼叫站點格式化消息與保存信息並在呼叫站點生成消息一樣好。問題是可能不需要格式化的消息。最好使用懶惰的消息生成方案 - 也許使用預先分配的內存。然後，如果需要消息，它將在訪問時生成（並且可能緩存在異常對象中）。因此，如果消息在被拋出時生成，那麼std :: exception派生，就像std :: runtime_error需要作爲基類一樣。如果消息是懶惰生成的，那麼std :: exception是合適的基礎。

Answer 13

在大型封裝系統上工作時，子類異常的另一個原因是更好的設計方面。您可以將其重用用於驗證消息，用戶查詢，致命控制器錯誤等。您可以簡單地將它「捕捉」在主源文件上，而不是重寫或重新鉤住所有驗證信息，而是將錯誤拋出到整個類集中的任何位置。

例如致命的異常會終止程序，驗證錯誤只會清除堆棧，用戶查詢會向最終用戶提出問題。

這樣做也意味着您可以重用相同的類，但在不同的接口上。例如一個Windows應用程序可以使用消息框，一個Web服務將顯示HTML並且報告系統將記錄它等等。

Answer 14

儘管這個問題是相當老已經回答了很多，我只想補充就怎麼做適當的異常處理在C++ 11的說明，因爲我不斷地失蹤這在有關異常的討論：

使用std::nested_exception和std::throw_with_nested

它是通過寫一個適當的異常處理程序在計算器上here和here，你怎麼能對你例外你的代碼中得到回溯，而不需要一個調試器或繁瑣的記錄，描述了將重新嵌套的excep蒸發散。

由於您可以對任何派生的異常類執行此操作，因此可以將大量信息添加到此類回溯中！ 您還可以看看我的MWE on GitHub，其中回溯會是這個樣子：

Library API: Exception caught in function 'api_function' 
Backtrace: 
~/Git/mwe-cpp-exception/src/detail/Library.cpp:17 : library_function failed 
~/Git/mwe-cpp-exception/src/detail/Library.cpp:13 : could not open file "nonexistent.txt" 

你甚至不需要爲了得到足夠的信息，以繼承std::runtime_error時拋出一個異常。

我在子類中看到的唯一好處（而不是僅使用std::runtime_error）是您的異常處理程序可以捕獲您的自定義異常並執行一些特殊的操作。例如：

try 
{ 
    // something that may throw 
} 
catch(const MyException & ex) 
{ 
    // do something specialized with the 
    // additional info inside MyException 
} 
catch(const std::exception & ex) 
{ 
    std::cerr << ex.what() << std::endl; 
} 
catch(...) 
{ 
    std::cerr << "unknown exception!" << std::endl; 
}