std::underflow_error
來自 cppreference.com
| 定義於標頭檔案 <stdexcept> |
||
| class underflow_error; |
||
定義一種作為異常丟擲的物件型別。它可用於報告算術下溢錯誤（即計算結果為次正規浮點值的情況）。
標準庫元件不會丟擲此異常（數學函式會按照 math_errhandling 中的規定報告下溢錯誤）。但是，第三方庫會使用此異常。例如，如果啟用了 `boost::math::policies::throw_on_error`（預設設定），boost.math 會丟擲 `std::underflow_error`。
繼承圖
目錄 |
[編輯] 成員函式
| (建構函式) |
使用給定訊息構造新的 `underflow_error` 物件 (公開成員函式) |
| operator= |
替換 `underflow_error` 物件 (公開成員函式) |
std::underflow_error::underflow_error
| underflow_error( const std::string& what_arg ); |
(1) | |
| underflow_error( const char* what_arg ); |
(2) | |
| underflow_error( const underflow_error& other ); |
(3) | (C++11 起無異常丟擲) |
3) 複製建構函式。如果 *this 和 other 都具有動態型別 `std::underflow_error`，則 std::strcmp(what(), other.what()) == 0。複製建構函式不能丟擲異常。
引數
| what_arg | - | 解釋性字串 |
| 其他 | - | 要複製的另一個異常物件 |
異常
1,2) 可能丟擲 std::bad_alloc。
注意
因為不允許複製 `std::underflow_error` 丟擲異常，所以此訊息通常以單獨分配的引用計數字符串的形式在內部儲存。這也是為什麼沒有接受 `std::string&&` 的建構函式：它無論如何都必須複製內容。
在 LWG issue 254 解決之前，非複製建構函式只能接受 std::string。為了構造 std::string 物件，這使得動態記憶體分配成為強制要求。
在 LWG issue 471 解決之後，派生標準異常類必須具有可公開訪問的複製建構函式。只要透過 `what()` 獲取的解釋字串對於原始物件和複製物件相同，就可以隱式定義它。
std::underflow_error::operator=
| underflow_error& operator=( const underflow_error& other ); |
(C++11 起無異常丟擲) | |
用 other 的內容賦值。如果 *this 和 other 都具有動態型別 `std::underflow_error`，則賦值後 std::strcmp(what(), other.what()) == 0。複製賦值運算子不能丟擲異常。
引數
| 其他 | - | 用於賦值的另一個異常物件 |
返回值
*this
注意
在 LWG issue 471 解決之後，派生標準異常類必須具有可公開訪問的複製賦值運算子。只要透過 `what()` 獲取的解釋字串對於原始物件和複製物件相同，就可以隱式定義它。
繼承自 std::exception
成員函式
| [虛] |
銷燬異常物件 （`std::exception` 的虛公共成員函式） |
| [虛] |
返回解釋字串 （`std::exception` 的虛公共成員函式） |
[編輯] 缺陷報告
下列更改行為的缺陷報告追溯地應用於以前出版的 C++ 標準。
| 缺陷報告 | 應用於 | 釋出時的行為 | 正確的行為 |
|---|---|---|---|
| LWG 254 | C++98 | 缺少接受 const char* 的建構函式 | 已新增 |
| LWG 471 | C++98 | `std::underflow_error` 的解釋字串 解釋性字串是實現定義的 |
它們與原始 std::runtime_error 物件的原始 `std::underflow_error` 物件 |
