Exception werfen

[Xebov]

Nexus schrieb:

Xebov schrieb:

wieso fragst du?

Weil es mich wundert, dass du dir die Mühe machst, eine fast nie auftretende Exception wie std::bad_alloc noch selbstständig weiterzuleiten. Ganz konsequent wirst du das wahrscheinlich nicht machen können...

Hast du etwas gegen die Exception-Hierarchie der Standardbibliothek?

Nein ich habe dagegen nichts. Ich bastel ne kleine Engine zusammen und die kommt halt aus einem Guß nun habe ich aber 2 verschiedene OutOfMemory Meldungen, einmal nen fehelrcode aus DX und einmal ne std::bad_alloc aus der std, und die leite ich beide auf eine eigene OutOfMemory Exception um.

Konsequent bin ich dabei ind er Tat nicht, da sis aber absicht, ich leite std::bad_alloc nur da um wo es sinn macht, dh Hauptsächlich wenn sich Interne Daten vergrößern, wenn aber Hauptteile "hochfahren" dann leite ich sie nicht um weil dann das Programm so oder so nicht weit käme.

[Tachyon]

Nexus schrieb:

[...Ich frage mich nach wie vor, wer für die Speicherverwaltung zuständig sein sollte, wenn der std::string einen neuen C-String erstellt...

Na std::string . Du bekommst über c_str() einen char const* zurück, der nur so lange gültig ist, wie es der String selbst ist. Es bleibt ja nach wie vor ein Puffer, dessen Eigentümer das String-Objekt ist. Selbst, wenn intern eine Kopie erzeugt wird.

[Shade Of Mine]

unskilled schrieb:

wenn man performance nicht nur über laufzeit definiert, sondern auch speicherverbrauch mitzählt, dann schon!

Nein...

Es geht hier um Exceptions - die treten in Ausnahmefällen auf. Hier einen optimalen Memory Footprint zu haben ist common sense und keine optimierung.

Idealerweise würde man nämlich 0 bytes allokieren, aber das ist nicht immer möglich.

[Nexus]

Tachyon schrieb:

Na std::string . Du bekommst über c_str() einen char const* zurück, der nur so lange gültig ist, wie es der String selbst ist. Es bleibt ja nach wie vor ein Puffer, dessen Eigentümer das String-Objekt ist. Selbst, wenn intern eine Kopie erzeugt wird.

Danke, das scheint Sinn zu machen. Ich war bis jetzt eher davon ausgegangen, dass in dem Falle, wo c_str() nicht der internen Repräsentation entspricht, ein eigenständiges Objekt zurückgegeben würde. Aber falls dieser Fall überhaupt vorkommt, gehört die Speicherverwaltung also dem String...

[Badestrand]

Tachyon schrieb:

Na std::string . Du bekommst über c_str() einen char const* zurück, der nur so lange gültig ist, wie es der String selbst ist. Es bleibt ja nach wie vor ein Puffer, dessen Eigentümer das String-Objekt ist. Selbst, wenn intern eine Kopie erzeugt wird.

Das hatten wir doch letztens schon einmal. Wie soll die Klasse sich um die Speicherverwaltung kümmern, wenn der c_str()-Aufruf das Objekt nicht verändern darf? Es geht mit Mörder-Frickelei und ausgelagerten Datenstrukturen, ja, aber nicht mit einer auch nur halbwegs praktikablen Lösung.

[Tachyon]

Badestrand schrieb:

...

c_str() muss das Objekt nicht ändern. Sollte hinter c_str() tatsächlich ein anderer Puffer stehen als hinter dem Stringpuffer selbst, so muss dieser bei jeder Ändererung des Stringpuffers mitgeändert werden. Nicht erst beim Aufruf von c_str() . c_str() selbst hat dabei nichts zu melden. Die Funktion muss immer nur einen konstanten Zeiger auf die aktuelle C-String-Repräsentation des Strings zurückgeben.
Und den (separaten) Puffer im Destruktor von std::basic_string zu zurstören beisst sich nicht im geringsten mit der constness von c_str() .
Irgendwelche "ausgelagerten Datenstrukturen" sind dabei völlig überflüssig.

[gambo]

Also ich habe im Moment folgende Exception struktur und weiß nicht so recht ob das Beispiel am Anfang von Dravere sinnvoll für mich wäre:

//irgendwo in main

try {

   try {

       // in diesem Teil wird das hauptprogramm sozusagen angstoßen mit
       // allen sub_routinen(). 
       foo();

    } catch (std::runtime_error &err)
      {
          std::cerr << err.what() << std::endl;
          // es folgt noch einiges zum exit
      } 

} catch (std::bad_alloc & err)
{
    std::cerr << err.what() << std::endl;
    // es folgt noch einiges zum exit
}

in meinem foo() und allen subroutinen gibt es dann bis jetzt immer nur immer ein

throw std::runtime_error("Hier steht dann meine Fehlermeldung");

Ich überlege jetzt die eigene exceptionsklasse von dravere zu übernehmen jedoch weiß ich nicht genau ob es sinn machen würde...ich habe schließlich doch nur lauf-zeitfehler oder nicht? Und wenn dann unterscheidet sich doch z.B. auch ein fehler bei division durch Null nur durch die message die geworfen wird. Wo ist der Unterschied? Ist meine bisherige struktur eher Blödsinn und wenn ja wie würdet ihr das schreiben?

[Nexus]

Kommt halt drauf an, wie stark du abstrahieren und unterscheiden willst. Wenn du sowieso alle Fehler gleich behandelst (kann ja sein), lohnt es sich auch nicht, für jeden Fehlertypen eine neue Klasse zu schreiben. Wenn du aber zum Beispiel noch zusätzliche Informationen in den Exceptions mittragen willst, kann sich eine eigene Klasse bewähren, da man da halt viel freier ist.

Warum machst du das so umständlich? Ich meine jetzt nicht mal die Einrückung, sondern die Verschachtelung der try s. Machs doch einfach so:

try
{
    // Fehleranfälliger Code
}
catch (std::runtime_error& e)
{
    // Behandle Laufzeitfehler
}
catch (std::bad_alloc& e)
{
    // Behandle Allokationsfehler
}

[gambo]

ah das wußte ich noch nicht.
Nur noch mal ne frage. Allein nur an der message würde sich was ändern...also der string sozusagen. Da machts doch wenig sinn da ne exception klasse mit unterschiedlichen exceptions zu bauen oder?

[Xebov]

gambo schrieb:

Ich überlege jetzt die eigene exceptionsklasse von dravere zu übernehmen jedoch weiß ich nicht genau ob es sinn machen würde...ich habe schließlich doch nur lauf-zeitfehler oder nicht? Und wenn dann unterscheidet sich doch z.B. auch ein fehler bei division durch Null nur durch die message die geworfen wird. Wo ist der Unterschied? Ist meine bisherige struktur eher Blödsinn und wenn ja wie würdet ihr das schreiben?

Schreiben siehe Nexus post.

Was den Sinn angeht, ich halte verschiedene Erbende Exceptions für durchaus sinnvoll. Der Punkt daran ist der du weißt was fliegt, du kannst passende aussagekräftige Klassennamen nehmen. Der Vorteil daran ist außerdem der, wenn du mit deinen nachrichten Exceptions wirfst, dann fliegt nur eine, aber du mußt die Strings immer vergleichen, hast du aber Exceptionklassen dann weißt du anhand der Klasse genau was Sache ist und kannst direkt loslegen, außerdem gibt das den catch Blöcken etwas mehr Struktur.

throw std::runtime_error("Device Lost");
throw std::runtime_error("Datei nicht gefunden");

throw e_MyException_Device("Device (hier Name eintragen) Lost");
throw e_MyException_File("Datei (hier Name eintragen) nicht gefunden");

Hier müsstest du oben imer die gleiche Nachricht nutzen, wärend du unten siehst was der Fehler ist und die Nachricht damit individuelelr sien kann, was sieht schöner aus?

[Badestrand]

Tachyon schrieb:

Die Funktion muss immer nur einen konstanten Zeiger auf die aktuelle C-String-Repräsentation des Strings zurückgeben.

Genau, zusammenhängendend und mit '\0' am Ende.

Wenn nicht mit mutable, externen oder static-Sachen gebastelt wird, also c_str() keine neue Kopie eines Buffers anfertigen kann (weil dann ja keiner aufräumen kann), muss hier

string s = "foo";
char& c = s[2]; // (1)
c = '.';        // (2)
s.c_str();      // (3)

bei (1) schon eine Referenz auf ein Element eines zusammenhängenden Null-terminierten Buffers zurückgegeben werden. Schließlich bekommt die string-Instanz nicht mit, wenn ich bei (2) etwas ändere, muss aber immer einen Null-terminierten String mit den Änderungen bereithalten. Und das geht eben nur, wenn direkt in den zusammenhängenden, Null-terminierten String geschrieben wird, der bei c_str() zurückgegeben wird.

[*john 0]

gambo schrieb:

} catch (std::runtime_error &err)
      {
          std::cerr << err.what() << std::endl;
          // es folgt noch einiges zum exit
      }

exit ist in so einer Situation nicht unbedingt der Weisheit letzter Schluß. Statische Objekte werden so nicht mehr destruiert und das Programm auf die harte Tour beendet, da kann man gleich abort() oder terminate() aufrufen.

Man sollte aus dem Hauptprogramm mittels "return EXIT_FAILURE;" rausgehen, das ist sauber und ordentlich.
So sähe das besser aus:

int main () {
    try {
        foo ();
    }
    catch (std::exception &e) {
        ...
        return EXIT_FAILURE;
    }
    catch (...) {
        ...
        return EXIT_FAILURE;
    }
}

[Tachyon]

Badestrand schrieb:

...

Okay, da ist was dran. Wie wärs dann mit mutable ? So gesehen in einer Implementation eines C++-Compilers für DSPs, bei dem der eigentliche String in einer deque-artigen Blockstruktur verwaltet wird, also nicht zusammenhängend. Der Puffer für den C-String ist mutabel und wird beim Aufruf von c_str() angepasst.
Grund dafür war laut Hersteller das etwas merkwürdig gehandhabte Speichermanagement.

PS: Das macht im Übrigen auch sinn, da mutable genau für solche Fälle gedacht ist: Die Änderung von Membern, ohne den Status des eigentlichen Objekts zu beeinflussen.

[Shade Of Mine]

Badestrand schrieb:

bei (1) schon eine Referenz auf ein Element eines zusammenhängenden Null-terminierten Buffers zurückgegeben werden

Ne.

c_str() ist eine Moment aufnahme. Jeder call zu einer nicht const Methodes des strings invalidiert den zeiger den dir c_str() geliefert hat.

[gambo]

throw e_MyException_Device("Device (hier Name eintragen) Lost");
throw e_MyException_File("Datei (hier Name eintragen) nicht gefunden");

Muss ich so nicht für jede unterschiedliche Exception eine neue Klasse entwerfen?

[Shade Of Mine]

gambo schrieb:

Muss ich so nicht für jede unterschiedliche Exception eine neue Klasse entwerfen?

ja, die 5 zeilen code wirst du aber schon noch hinbekommen... kannst es ja auch deine ide generieren lassen.

viele unterschiedliche klassen ist gut. denn wie willst du unterschiedliche fehler erkennen wenn alles nur "irgendein fehler" ist? dann kommt das tolle "es ist ein unbekannter fehler aufgetreten" heraus. doof sowas.

[Xebov]

gambo schrieb:

Muss ich so nicht für jede unterschiedliche Exception eine neue Klasse entwerfen?

Ja, du musst die Möglichen fehler anschaun und Ordnen udn danach Klassen erstellen, die sind auch meist sehr klein. Der Vorteil an der sache ist du kanst auchmal Spezielel Daten mitgeben bzw einen richtigen text mitgeben den du dann zB in ein Log ausgeben kannst. Und wie Shade schon sagte es gibt da nichts schlimmeres als ein Ergebniss alla "Es ist ein Fehler aufgetreten, leider wissen wir nicht was passiert ist".

[Dravere]

Wegen unterschiedlichen Klassen bei unterschiedlichen Fehlern:
Wenn die Informationen, welche mitgetragen werden, gleich bleiben, was haltet ihr eigentlich von so einem Lösungsansatz?

template<int>
class BasicExceptionWithMessage
  : public std::exception // oder was auch immer.
{
  // ... usw.
  std::string m_message;
  // ... usw.
};

// Also wir haben eine grundlegende Schablone für Exceptions.
// Danach:
typedef BasicExceptionWithMessage<0> MathException;
typedef BasicExceptionWithMessage<1> IOException;
typedef BasicExceptionWithMessage<2> // usw.
// usw. ...

Grüssli

[Tachyon]

Dravere schrieb:

...was haltet ihr eigentlich von so einem Lösungsansatz?

Finde ich okay, und habe ich auch schon gemacht. Allerdings mit einem enum, damit man sprechendere Tags hat.

[Badestrand]

Tachyon schrieb:

Wie wärs dann mit mutable ? So gesehen in einer Implementation eines C++-Compilers für DSPs, bei dem der eigentliche String in einer deque-artigen Blockstruktur verwaltet wird, also nicht zusammenhängend. Der Puffer für den C-String ist mutabel und wird beim Aufruf von c_str() angepasst.
Grund dafür war laut Hersteller das etwas merkwürdig gehandhabte Speichermanagement.

Das macht Sinn und bei nicht-Desktop-Anwendungen würde ich mich auf 0-terminiert bei op[] auch nicht verlassen.

Shade Of Mine schrieb:

Badestrand schrieb:

bei (1) schon eine Referenz auf ein Element eines zusammenhängenden Null-terminierten Buffers zurückgegeben werden

c_str() ist eine Moment aufnahme. Jeder call zu einer nicht const Methodes des strings invalidiert den zeiger den dir c_str() geliefert hat.

Vielleicht hättest du dir den kompletten Post durchlesen sollen.