C++異常機制解析
傳統排錯
我們早在 C 程序里面傳統的錯誤處理手段有：
- 終止程序，如 assert；缺陷是用戶難以接受，說白了就是一種及其粗暴的手法，比如發生內存錯誤，除0錯誤時就會終止程序。
- 返回錯誤碼。缺陷是需要我們自己去查找錯誤，如系統的很多庫的接口函數都是通過把錯誤碼放到 errno 中，表示錯誤。
- C標準庫中 setjmp 和 longjmp 組合（不常用）
實際中 C 語言基本都是使用返回錯誤碼的方式處理錯誤，部分情況下使用終止程序處理非常嚴重緊急的錯誤，因此異常機制就時運而橫空出世
概念
異常是面向對象語言常用的一種處理錯誤的方式，當一個函數發現自己無法處理的錯誤時就可以拋出異常，讓函數直接或間接調用者自己來處理這個錯誤
- throw：當程序出現問題時，可以通過 throw 關鍵字拋出一個異常
- try：try 塊中放置的是可能拋出異常的代碼，該代碼塊在執行時將進行異常錯誤檢測，try 塊后面通常跟著一個或多個 catch 塊。
- catch：如果try塊中發生錯誤，則可以在 catch 塊中定義對應要執行的代碼塊。
try-catch 語句的語法實例：
{
//被保護的代碼
}
catch (ExceptionName e1)
{
//catch塊
}
catch (ExceptionName e2)
{
//catch塊
}
catch (ExceptionName eN)
{
//catch塊
}
用法
異常是通過拋出對象而引發的，該對象的類型決定了應該激活哪個 catch 的處理代碼，如果拋出的異常對象沒有捕獲，或是沒有匹配類型的捕獲，那么程序會終止報錯
異常捕獲和拋出
被選中的處理代碼（catch塊）是調用鏈中與該對象類型匹配且離拋出異常位置最近的那一個
拋出異常對象后，會生成一個異常對象的拷貝，因為拋出的異常對象可能是一個臨時對象，所以會生成一個拷貝對象 color{red} {因為拋出的異常對象可能是一個臨時對象，所以會生成一個拷貝對象}因為拋出的異常對象可能是一個臨時對象，所以會生成一個拷貝對象，這個拷貝的臨時對象會在被 catch 以后銷毀（類似于函數的傳值返回）
catch(…) 可以捕獲任意類型的異常，但捕獲后無法知道異常錯誤是什么，實際異常拋出和捕獲的匹配原則有個例外，捕獲和拋出的異常類型并不一定要完全匹配，可以拋出派生類對象，使用基類進行捕獲，這個在實際中非常有用
在函數調用鏈中異常棧展開的匹配原則：
當異常被拋出后，首先檢查 throw 本身是否在 try 塊內部，如果在則查找匹配的 catch 語句，如果有匹配的就跳到 catch 的地方進行處理
如果當前沒有匹配的 catch 則退出當前函數棧，繼續在上一個調用中進行查找 catch。找到匹配的 catch 子句并處理以后，會沿著 catch 子句后面繼續執行，而不會跳回到原來拋異常的地方，如果到達 main 函數的棧，依舊沒有找到匹配的 catch 則終止程序
比如下面的代碼中調用了 func3，func3 中調用 func2，func2 中調用 func1，func1 中拋出了一個 string 的異常對象：
{
throw string("這是一個異常");
}
void func2()
{
func1();
}
void func3()
{
func2();
}
int main()
{
try
{
func3();
}
catch (const string& s)
{
cout << "錯誤描述：" << s << endl;
}
catch (...)
{
cout << "未知異常" << endl;
}
return 0;
}
首先會檢查 throw 本身是否在 try 塊內部，這里就會因此退出 func1 所在的函數棧，繼續在上一個調用棧中進行查找，即 func2 所在的函數棧，由于 func2 中也沒有匹配的 catch，因此會繼續復讀套娃，最終在 main 函數棧中找到匹配的 catch
這時就會跳到 main 函數中對應的 catch 塊中執行對應的代碼塊，執行完后繼續執行該代碼塊后續的代碼：
當然為了防止還有漏網之魚，一般此時我們還會搞一個 catch(…) 進行全捕獲。
異常的重新拋出
要知道一個 catch 是無法完全搞定異常的，如果我們對異常進行修正后，希望交付給上層調用鏈進行異常的異常信息日志記錄，此時就需要我們重新對上層函數拋異常：
{
throw string("這是一個異常");
}
void func2()
{
int* array = new int[10];
func1();
//省略函數對應實現
//……
delete[] array;
}
int main()
{
try
{
func2();
}
catch (const string& s)
{
cout << s << endl;
}
catch (...)
{
cout << "未知異常" << endl;
}
return 0;
}
這里 func2 最后應該 delete 進行空間釋放，但由于 func2 中途調用 func1 ，func1 內部拋出了一個異常，這時會直接跳轉到 main 函數中的 catch 塊執行對應的異常處理程序，并且在處理完后繼續沿著 catch 塊往后執行，這時就導致 func2 中內存塊沒有得到釋放，造成了內存泄露！
此時我們應該在 func2 中先對 func1 拋出的異常進行捕獲，捕獲后先將內存釋放再重新拋出異常，就可以避免內存泄露：
{
int* array = new int[10];
try
{
func1();
//省略函數對應實現
//……
}
catch (...)
{
delete[] array;
throw; //將捕獲到的異常再次重新拋出
}
delete[] array;
}
try-catch 中 new 和 delete 之間可能還會拋出其他類型的異常，因此在 fun2 中最好再進行 catch(…) ，將申請到的內存 delete 后再通過throw 重新拋出；重新拋出異常對象時，此時 throw 可以不用指明要拋出的異常對象，其實 catch(…) 也不知道自己到底捕了個什么異常對象
安全第一條
還是那句話，道路千萬條，拋異常要謹慎：
- 構造函數完成對象的構造和初始化，最好不要在構造函數中拋出異常，否則可能導致對象不完整或沒有完全初始化
- 析構函數完成對象資源的清理，最好不要在析構函數中拋出異常，否則可能導致內存泄露，句柄未關閉等
- C++ 中在 new 和 delete 中拋出異常經常是內存泄漏的罪魁禍首，在 lock 和 unlock 之間拋出異常導致死鎖，C++ 經常使用 RAII 的方式來解決類似問題
規范使用
站在異常的嚴謹立場上， C++ 也在盡量提高咱的使用規范：
在函數的后面接throw(type1, type2, …)，列出這個函數可能拋擲的所有異常類型
在函數的后面接throw()或noexcept（C++11），表示該函數不拋異常
若無異常接口聲明，則此函數可以拋擲任何類型的異常（異常接口聲明不是強制的）
void func() throw(A, B, C, D);
//這里只會拋出 bad_alloc 的異常
void* operator new(std::size_t size) throw(std::bad_alloc);
//這里不會拋出異常
void* operator new(std::size_t size, void* ptr) throw();
異常體系
因為異常屬實需要嚴謹與規范的操作，所以在很多公司里面都會制定自己的一套異常的規范管理：
公司中的項目一般會進行模塊劃分，讓不同的人或小組完成不同的模塊，如果不對拋異常這件事進行規范，那么在最外層捕獲異常的冤種就會問候親媽了，因為他會來給各位擦屁股，捕獲大家拋出的所以異常對象 color{red} {那么在最外層捕獲異常的冤種就會問候親媽了，因為他會來給各位擦屁股，捕獲大家拋出的所以異常對象}那么在最外層捕獲異常的冤種就會問候親媽了，因為他會來給各位擦屁股，捕獲大家拋出的所以異常對象
我們之前說過異常語法可以用基類捕獲拋出的派生類對象，因此實際中都會先定義一個最基礎的異常類，所有人拋出的異常對象都必須是繼承于該異常類的派生類對象，，因此最外層就只需捕獲基類就行了
最基礎的異常類至少需要包含錯誤編號和錯誤描述兩個成員變量，甚至還可以包含當前函數棧幀的調用鏈等信息，該異常類中一般還會提供兩個成員函數，分別用來獲取錯誤編號和錯誤描述
{
public:
Exception(int errid, const char* errmsg)
:_errid(errid)
, _errmsg(errmsg)
{}
int GetErrid() const
{
return _errid;
}
virtual string what() const
{
return _errmsg;
}
protected:
int _errid; //錯誤編號
string _errmsg; //錯誤描述
//...
};
其他人如果要對這個異常類進行擴展，必須先繼承基礎異常類，然后按需添加某些成員變量，或是對虛函數what 進行重寫，使其能告知更多的異常信息：
{
public:
CacheException(int errid, const char* errmsg)
:Exception(errid, errmsg)
{}
virtual string what() const
{
string msg = "CacheException: ";
msg += _errmsg;
return msg;
}
protected:
//...
};
class SqlException : public Exception
{
public:
SqlException(int errid, const char* errmsg, const char* sql)
:Exception(errid, errmsg)
, _sql(sql)
{}
virtual string what() const
{
string msg = "CacheException: ";
msg += _errmsg;
msg += "sql語句: ";
msg += _sql;
return msg;
}
protected:
string _sql; //異常的SQL語句
//...
};
異常類的成員變量不能設置為私有，因為私有成員在子類中是不可見的。基類 Exception 中 what 成員函數最好定義為虛函數，方便子類對其進行重寫，從而達到多態的效果
標準庫體系
C++ 標準庫當中的異常也是一個基礎體系，其中 exception 就是基類，它與其他異常類的繼承關系如下：
其中具體信息如下：
我們可以去繼承這里的 exception 類來實現自己的異常類，但實際上很多公司都會自己定義一套異常繼承體系！
優缺點
目前情況來看，異常是利大于弊的，還是鼓勵使用異常的，而且前排的語言基本都會使用異常處理錯誤，這也可以看出這是大勢所趨
異常的優點：
相比錯誤碼，異?？梢郧逦鷾蚀_的展示出錯誤的各種信息，甚至可以包含堆棧調用等信息，這樣可以幫助更好的定位程序的bug
返回錯誤碼的傳統方式有個很大的問題就是，在函數調用鏈中，深層的函數返回了錯誤，那么我們得層層返回錯誤碼，最終最外層才能拿到錯誤
很多的第三方庫都會使用異常，比如 boost、gtest、gmock 等常用的庫，如果我們不用異常就不能很好的發揮這些庫的作用，很多測試框架也都使用異常，因此使用異常能更好的使用單元測試等進行白盒測試
部分函數使用異常更好處理，比如 T& operator 這樣的函數，如果 pos 越界了只能使用異常或者終止程序處理，沒辦法通過返回值表示錯誤
異常的缺點：
異常會導致程序的執行流混亂，這會導致我們跟蹤調試或分析程序時比較困難。異常還會有一些性能的開銷，當然在現代硬件速度很快的情況下，這個影響基本忽略不計！
C++ 沒有垃圾回收機制，資源需要自己管理，有了異常非常容易導致內存泄露、死鎖等異常安全問題，這個需要使用 RAII 來處理資源的管理問題，學習成本比較高
C++ 標準庫的異常體系定義得不夠好，導致大家各自定義自己的異常體系，非常的混亂，異常盡量規范使用，否則后果不堪設想，隨意拋異常，也會讓外層捕獲的用戶苦不堪言。
異常接口聲明不是強制的，對于沒有聲明異常類型的函數，無法預知該函數是否會拋出異常
-
模塊
+關注
關注
7文章
2731瀏覽量
47661 -
程序
+關注
關注
117文章
3795瀏覽量
81299 -
函數
+關注
關注
3文章
4345瀏覽量
62875 -
C++
+關注
關注
22文章
2114瀏覽量
73792
發布評論請先 登錄
相關推薦
工商網監
評論