std::ios_base:: failure
|
Definiert im Header
<ios>
|
||
|
class
failure
;
|
||
Die Klasse
std::ios_base::failure
definiert ein Ausnahmeobjekt, das bei Fehlern von den Funktionen der Eingabe/Ausgabe-Bibliothek ausgelöst wird.
|
|
(seit C++17) |
|
Vererbungsdiagramm |
(bis C++11) |
|
Vererbungsdiagramm |
(seit C++11) |
Inhaltsverzeichnis |
Memberfunktionen
|
(Konstruktor)
|
konstruiert ein neues
failure
-Objekt mit der angegebenen Nachricht
(öffentliche Elementfunktion) |
|
operator=
|
ersetzt das
failure
-Objekt
(öffentliche Elementfunktion) |
|
what
|
gibt die erläuternde Zeichenkette zurück
(öffentliche Elementfunktion) |
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 | - | erläuternde Zeichenkette |
| ec | - | Fehlercode zur Identifizierung des spezifischen Fehlergrunds |
| other | - |
ein weiteres
failure
zum Kopieren
|
Anmerkungen
Da das Kopieren von
std::ios_base::failure
keine Ausnahmen werfen darf, wird diese Nachricht typischerweise intern als separat allokierte referenzgezählte Zeichenkette gespeichert. Dies ist auch der Grund, warum es keinen Konstruktor gibt, der
std::
string
&&
akzeptiert: 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 die Inhalte mit denen 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
| other | - | ein weiteres 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 erklärenden Informationen. Der String ist geeignet für Konvertierung und Anzeige als std::wstring . Der Zeiger ist garantiert mindestens so lange gültig, bis das Ausnahmeobjekt, von dem er erhalten wurde, zerstört wird, oder bis eine nicht-konstante Memberfunktion (z.B. Kopierzuweisungsoperator) auf dem Ausnahmeobjekt aufgerufen wird.
Anmerkungen
Implementierungen dürfen, müssen aber nicht
what()
überschreiben.
Geerbt von std:: system_error
Elementfunktionen
|
gibt Fehlercode zurück
(öffentliche Elementfunktion von
std::system_error
)
|
|
|
[virtual]
|
gibt erläuternde Zeichenkette zurück
(virtuelle öffentliche Elementfunktion von
std::system_error
)
|
Geerbt von std:: runtime_error
Geerbt von std:: exception
Elementfunktionen
|
[virtual]
|
zerstört das Exception-Objekt
(virtuelle öffentliche Elementfunktion von
std::exception
)
|
|
[virtual]
|
gibt einen erläuternden String zurück
(virtuelle öffentliche Elementfunktion von
std::exception
)
|
Hinweise
Vor der Lösung von
LWG Issue 331
deklarierte
std::ios_base::failure
einen Destruktor ohne
throw
(
)
, während
std::exception::~exception()
mit
throw
(
)
[1]
deklariert war. Dies bedeutete, dass
std::ios_base::failure::~failure()
eine schwächere Exception-Spezifikation hatte. Die Lösung besteht darin, diese Deklaration zu entfernen, sodass die nicht-werfende Exception-Spezifikation beibehalten wird.
LWG Issue 363
zielt auf denselben Defekt ab und seine Lösung besteht darin,
throw
(
)
zur Deklaration von
std::ios_base::failure::~failure()
hinzuzufügen. Diese Lösung wurde aufgrund des Konflikts zwischen den beiden Lösungsansätzen nicht übernommen.
- ↑ Die nicht-werfende Ausnahmespezifikation wird nun global über die Standardbibliothek hinweg angewendet , daher sind die Destruktoren der Standardbibliotheksklassen nicht mit throw ( ) oder noexcept deklariert.
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
Fehlerberichte
Die folgenden verhaltensändernden Fehlerberichte wurden rückwirkend auf zuvor veröffentlichte C++-Standards angewendet.
| DR | Angewendet auf | Verhalten wie veröffentlicht | Korrektes Verhalten |
|---|---|---|---|
| LWG 48 | C++98 |
der Konstruktor-Overload (1) initialisierte die Basisklasse
std::exception
mit msg , aber die Basisklasse hat keinen passenden Konstruktor |
entsprechende
Beschreibung entfernt |
| LWG 331 | C++98 |
std::ios_base::failure
deklarierte einen Destruktor ohne
throw
(
)
|
entfernte die Destruktordeklaration |
Siehe auch
|
(C++11)
|
Die IO-Stream-Fehlercodes
(enum) |