Namespaces
Variants

std::ios_base:: failure

From cppreference.net
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.

std::ios_base::failure kann entweder als eine Member-Klasse von std::ios_base oder als ein Synonym (typedef) für eine andere Klasse mit äquivalenter Funktionalität definiert werden.

(seit C++17)
cpp/error/exception std-ios base-failure-2003-inheritance.svg

Vererbungsdiagramm

(bis C++11)
cpp/error/exception cpp/error/runtime error cpp/error/system error std-ios base-failure-inheritance.svg

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)
1,2) Konstruiert das Ausnahmeobjekt mit message als Erklärungszeichenkette, die später mit what() abgerufen werden kann. ec wird verwendet, um den spezifischen Grund des Fehlers zu identifizieren. (seit C++11)
3) Kopierkonstruktor. Initialisiert die Inhalte mit denen von other . Wenn * this und other beide den dynamischen Typ 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:: 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.

  1. 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)