bei nem bad_alloc würde sich ein string natürlich eher weniger anbieten...^^ (da man sich nicht auf implementierungsdetails verlassen sollte - die nächste standard-lib bietet dieses feature eben nicht und eine exception beim konstruieren einer exception -> BÄM!)
ansonsten ist das relativ egal - und ein string ist natürlich bequemer und idR auch sinnvoller...

bb

... - standard-bibliotheken nutzen aber idR referenz-zähler und so muss nix umkopiert werden...

Halte ich für eine gewagte Aussage, vor allem da sich solche Dinge schnell mal ändern können. COW hat nämlich auch einiges an Nachteile.

unskilled schrieb:

... - und ein string ist natürlich bequemer und idR auch sinnvoller...

wx++ schrieb:

Warum und wie sollte man es selber halten?

Ich fühle mich dazu geneigt hier eine Diskussion anzustossen, welche ganz im Sinne von diesem Thread sein dürfte:
Wie sinnvoll ist es überhaupt einen std::string oder char const* in einer Exception zu liefern? Meine Alternative wäre grundsätzlich ein Fehlercode wie in C, könnte man allerdings auch als enum mitgeben.

Der Hintergrund dieser Überlegung betrifft zwei Punkte:
1. Auf unterschiedliche Beschreibung kann ich sehr schlecht bis gar nicht reagieren. Ich kann somit die Beschreibung nur irgendwo in ein Log schreiben und das ist alles.
2. Wenn ich die Fehlermeldungen in einer anderen Sprache haben möchte, bin ich ebenfalls aufgeschmissen.

Zeichenketten sind einfach etwas sehr absolutes und bereits fertiges. Die Fehlerbehandlung sollte nicht beim Ort geschehen, wo der Fehler geworfen wird. Ein Fehler wird dort behandelt, wo er gefangen wird und daher sollte dort auch die Fehlerbeschreibung entstehen. Über statische Funktionen könnte man ja immer noch die Standardfehlerbeschreibung anbieten.

Was meint ihr dazu?

Grüssli

Was meint ihr dazu?

Was ist, wenn du die Information mitliefern willst, wo der Fehler aufgetreten ist?
Außerdem bist du dann inkompatibel zu std::exception.

Was ist, wenn du die Information mitliefern willst, wo der Fehler aufgetreten ist?

Sowas schreibt man bereits heute nicht in die Zeichenkette, sondern liefert es als zusätzliche Daten mit.

wx++ schrieb:

Außerdem bist du dann inkompatibel zu std::exception.

Das ist mir egal. Ich will ja eine neue Idee reinbringen. Alle Exception-Klassenhierarchien, welche ich bisher gesehen habe, hatten eine Beschreibung im geworfenen Objekt, worin ich allerdings keinerlei Vorteile sehe, eher nur Nachteile.

Grüssli

Sowas schreibt man bereits heute nicht in die Zeichenkette, sondern liefert es als zusätzliche Daten mit.

Wobei wir wieder bei string vs char* wären.

Sowas schreibt man bereits heute nicht in die Zeichenkette, sondern liefert es als zusätzliche Daten mit.

Wobei wir wieder bei string vs char* wären.

Für Funktionsnamen, Klassennamen usw. usf. nimmst du sowieso char const* , da du immer auf String-Literale verweisen kannst. Für die Zeile nimmst du einen int oder unsigned int .

Die von dir gestellte Frage bleibt nur für die Beschreibung zurück und da schlage ich eben als dritte Möglichkeit die Fehlercodes vor.

Grüssli

bb

wie oft logst du fkt-name und zeilennr mit? ich eigtl nie...

Ich eigentlich auch nie, ging mir nur um das Wenn, weil wx++ es aufgebracht hat.

unskilled schrieb:

der fehlercode erübrigt sich in 99% der fälle, weil die exception nur für diesen zweck ist...

Sehe ich nicht so. Meistens gibt es mehrere Gründe, wieso eine Exception geflogen kommen kann. Und ich würde halt eine allgemeine Hierachie aufbauen wollen, bzw. vorschlagen, dass zum Beispiel eine Grundklasse wie std::exception mit der Funktion what , nicht einen char const* sondern einen Fehlercode zurückliefern soll.

Grüssli

In den boost-guidelines für Exceptions steht, in einer Exception-Klasse sollte man kein std::string-Objekt zu verwenden, da dieses ja wieder eine Exception werfen könnte. Die Standardbibliothek tut das aber trotzdem - z.B. in runtime_error.
Warum und wie sollte man es selber halten?

Das ist in der Standardbibliothek schlecht beziehungsweise gar nicht gelöst. Wenn man es genau nimmt, dann kann man kein std::string in eine Exception packen. Wenn du dir die Implementierung von einigen Compiler anschaust, dann siehst du, dass die intern ein char-Array als Member enthalten. In der Praxis bleibt dir aber eh nicht viel übrig außer abstürzen, wenn der Speicher wirklich voll ist, von daher: Lass es knallen.

Was auch oft eine Möglichkeit ist, ist folgendes:

class foo:public std::exception{
public:
  const char*what()const throw(){
    return typeid(*this).name();
  }
};