Namensräume
Varianten
Aktionen

std::range_error

Von cppreference.com
< cpp‎ | error
 
 
 
Definiert in der Header-Datei <stdexcept>
class range_error;

Definiert einen Objekttyp, der als Ausnahme geworfen werden kann. Er kann verwendet werden, um Bereichsfehler zu melden (d. h. Situationen, in denen das Ergebnis einer Berechnung nicht durch den Zieltyp dargestellt werden kann).

Die einzigen Komponenten der Standardbibliothek, die diese Ausnahme auslösen, sind std::wstring_convert::from_bytes und std::wstring_convert::to_bytes.

Die mathematischen Funktionen in den Komponenten der Standardbibliothek lösen diese Ausnahme nicht aus (mathematische Funktionen melden Bereichsfehler wie in math_errhandling angegeben).

cpp/error/exceptioncpp/error/runtime errorstd-range error-inheritance.svg

Vererbungdiagramm

Inhalt

[edit] Member functions

(Konstruktor)
konstruiert ein neues range_error-Objekt mit der angegebenen Nachricht
(öffentliche Memberfunktion)
operator=
ersetzt das range_error-Objekt
(öffentliche Memberfunktion)

std::range_error::range_error

range_error( const std::string& what_arg );
(1)
range_error( const char* what_arg );
(2)
range_error( const range_error& other );
(3) (noexcept seit C++11)
1) Konstruiert das Ausnahmeobjekt mit what_arg als erklärende Zeichenkette. Nach der Konstruktion gilt std::strcmp(what(), what_arg.c_str()) == 0.
2) Konstruiert das Ausnahmeobjekt mit what_arg als erklärende Zeichenkette. Nach der Konstruktion gilt std::strcmp(what(), what_arg) == 0.
3) Kopierkonstruktor. Wenn *this und other beide den dynamischen Typ std::range_error haben, dann ist std::strcmp(what(), other.what()) == 0. Es kann keine Ausnahme vom Kopierkonstruktor ausgelöst werden.

Parameter

what_arg - erklärende Zeichenkette
Sonstiges - ein anderes Ausnahmeobjekt zum Kopieren

Ausnahmen

1,2) Kann std::bad_alloc auslösen.

Anmerkungen

Da das Kopieren von std::range_error keine Ausnahmen auslösen darf, wird diese Nachricht typischerweise intern als separat zugeordneter referenzgezählter String gespeichert. Dies ist auch der Grund, warum es keinen Konstruktor gibt, der std::string&& nimmt: Er müsste den Inhalt ohnehin kopieren.

Vor der Auflösung von LWG-Problem 254 konnte der Nicht-Kopierkonstruktor nur std::string akzeptieren. Dies machte die dynamische Speicherzuweisung zur obligatorischen Erstellung eines std::string-Objekts.

Nach der Auflösung von LWG-Problem 471 muss eine abgeleitete Standard-Ausnahmeklasse einen öffentlich zugänglichen Kopierkonstruktor haben. Dieser kann implizit definiert werden, solange die durch what() erhaltenen erklärenden Zeichenketten für das ursprüngliche und das kopierte Objekt gleich sind.

std::range_error::operator=

range_error& operator=( const range_error& other );
(noexcept seit C++11)

Weist den Inhalt von other zu. Wenn *this und other beide den dynamischen Typ std::range_error haben, dann ist std::strcmp(what(), other.what()) == 0 nach der Zuweisung. Vom Kopierzuweisungsoperator kann keine Ausnahme ausgelöst werden.

Parameter

Sonstiges - ein anderes Ausnahmeobjekt zum Zuweisen

Rückgabewert

*this

Anmerkungen

Nach der Auflösung von LWG-Problem 471 muss eine abgeleitete Standard-Ausnahmeklasse einen öffentlich zugänglichen Kopierzuweisungsoperator haben. Dieser kann implizit definiert werden, solange die durch what() erhaltenen erklärenden Zeichenketten für das ursprüngliche und das zugewiesene Objekt gleich sind.

Geerbt von std::runtime_error


Abgeleitet von std::exception

Memberfunktionen

[virtuell]
zerstört das Ausnahmeobjekt
(virtuelle öffentliche Memberfunktion von std::exception) [bearbeiten]
[virtuell]
gibt einen erklärenden String zurück
(virtuelle öffentliche Memberfunktion von std::exception) [bearbeiten]

[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 254 C++98 Der Konstruktor, der const char* akzeptiert, fehlte hinzugefügt
LWG 471 C++98 die erklärenden Strings von std::range_error
Kopien waren implementierungsabhängig
sie sind identisch mit der des
originales std::range_error-Objekt