std::ios_base::failure
| Definiert in Header <ios> |
||
| class failure; |
||
Die Klasse std::ios_base::failure definiert ein Ausnahmeobjekt, das bei einem Fehler von den Funktionen der Input/Output-Bibliothek ausgelöst wird.
|
|
(seit C++17) |
 Vererbungdiagramm |
(bis C++11) |
 Vererbungdiagramm |
(seit C++11) |
Inhalt |
[edit] Member Functions
| (Konstruktor) |
Konstruiert ein neues failure-Objekt mit der gegebenen Nachricht(öffentliche Memberfunktion) |
| operator= |
Ersetzt das failure-Objekt(öffentliche Memberfunktion) |
| what |
gibt den erklärenden String zurück (öffentliche Memberfunktion) |
std::ios_base::failure::failure
| (1) | ||
explicit failure( const std::string& message ); |
(bis C++11) | |
| explicit failure( const std::string& message, const std::error_code& ec = std::io_errc::stream ); |
(seit C++11) | |
| explicit failure( const char* message, const std::error_code& ec = std::io_errc::stream ); |
(2) | (seit C++11) |
| (3) | ||
failure( const failure& other ); |
(bis C++11) | |
| failure( const failure& other ) noexcept; |
(seit C++11) | |
std::ios_base::failure haben, dann gilt std::strcmp(what(), other.what()) = 0.(seit C++11)Parameter
| message | - | erklärende Zeichenkette |
| ec | - | Fehlercode zur Identifizierung des spezifischen Grundes für den Fehler |
| Sonstiges | - | eine weitere zu kopierende failure |
Anmerkungen
Da das Kopieren von std::ios_base::failure keine Ausnahmen auslösen darf, wird diese Nachricht typischerweise intern als separat zugewiesener, referenzgezählter String gespeichert. Dies ist auch der Grund, warum es keinen Konstruktor gibt, der std::string&& nimmt: der Inhalt müsste ohnehin kopiert werden.
std::ios_base::failure::operator=
| failure& operator=( const failure& other ); |
(bis C++11) | |
| failure& operator=( const failure& other ) noexcept; |
(seit C++11) | |
Weist den Inhalt dem von other zu. Wenn *this und other beide den dynamischen Typ std::ios_base::failure haben, dann gilt std::strcmp(what(), other.what()) = 0 nach der Zuweisung.(seit C++11)
Parameter
| Sonstiges | - | ein anderes Ausnahmeobjekt zum Zuweisen |
Rückgabewert
*this
std::ios_base::failure::what
| virtual const char* what() const throw(); |
(bis C++11) | |
virtual const char* what() const noexcept; |
(seit C++11) | |
Gibt den erklärenden String zurück.
Rückgabewert
Zeiger auf einen implementierungsdefinierten, nullterminierten String mit erläuternden Informationen. Der String kann für die Konvertierung und Anzeige als std::wstring verwendet werden. Der Zeiger ist garantiert gültig, mindestens bis das Ausnahmeobjekt, von dem er stammt, zerstört wird, oder bis eine nicht-const Memberfunktion (z. B. der Kopierzuweisungsoperator) für das Ausnahmeobjekt aufgerufen wird.
|
Der zurückgegebene String ist während der konstanten Auswertung mit der gewöhnlichen Literal-Codierung kodiert. |
(seit C++26) |
Anmerkungen
Implementierungen dürfen what() überschreiben, sind aber nicht dazu verpflichtet.
Erbt von std::system_error
Memberfunktionen
| gibt den Fehlercode zurück (öffentliche Memberfunktion von std::system_error) | |
| [virtuell] |
gibt einen erklärenden String zurück (virtuelle öffentliche Memberfunktion von std::system_error) |
Geerbt von std::runtime_error
Abgeleitet von std::exception
Memberfunktionen
| [virtuell] |
zerstört das Ausnahmeobjekt (virtuelle öffentliche Memberfunktion von std::exception) |
| [virtuell] |
gibt einen erklärenden String zurück (virtuelle öffentliche Memberfunktion von std::exception) |
[edit] Hinweise
Vor der Auflösung von LWG issue 331 deklarierte std::ios_base::failure einen Destruktor ohne throw(), während std::exception::~exception() mit throw() deklariert war[1]. Dies bedeutet, dass std::ios_base::failure::~failure() eine schwächere Exceptionspezifikation hatte. Die Auflösung besteht darin, diese Deklaration zu entfernen, damit die nicht-werfende Exceptionspezifikation beibehalten wird.
LWG issue 363 befasst sich mit demselben Fehler und seine Auflösung besteht darin, throw() zur Deklaration von std::ios_base::failure::~failure() hinzuzufügen. Diese Auflösung wurde aufgrund des Konflikts zwischen den beiden Auflösungen nicht angewendet.
- ↑ Die nicht-werfende Exceptionspezifikation wird nun global in der gesamten Standardbibliothek angewendet, sodass die Destruktoren von Klassen der Standardbibliothek nicht mit throw() oder noexcept deklariert werden.
[edit] Beispiel
#include <fstream> #include <iostream> int main() { std::ifstream f("doesn't exist"); try { f.exceptions(f.failbit); } catch (const std::ios_base::failure& e) { std::cout << "Caught an ios_base::failure.\n" << "Explanatory string: " << e.what() << '\n' << "Error code: " << e.code() << '\n'; } }
Mögliche Ausgabe
Caught an ios_base::failure. Explanatory string: ios_base::clear: unspecified iostream_category error Error code: iostream:1
[edit] Defect Reports
Die folgenden Verhaltensändernden Fehlerberichte wurden rückwirkend auf zuvor veröffentlichte C++-Standards angewendet.
| DR | angewendet auf | Verhalten wie veröffentlicht | Korrigiertes Verhalten |
|---|---|---|---|
| LWG 48 | C++98 | die Konstruktorüberladung (1) initialisierte die Basisklasse std::exception mit msg, aber die Basisklasse hat keinen passenden Konstruktor |
entsprechend Beschreibung entfernt |
| LWG 331 | C++98 | std::ios_base::failure deklarierte einen Destruktor ohne throw() |
Deklaration des Destruktors entfernt |
[edit] Siehe auch
| (C++11) |
die IO-Stream-Fehlercodes (Aufzählung) |
