Exception werfen

*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.

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.

hui...interessant...

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

meinst du dann sowas wie eine klassen-instantiierung über z.B.

BasicExceptionWithMessage<Math> MyExcept;

??

Shade Of Mine

Dravere schrieb:

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

Garnix, da kann man keine vernünftigen hierachien einbauen und hierachien sind das was exceptions toll machen. sonst kann man ja gleich integer werfen...

ich will IOError fangen können oder aber BadBlockError oder FileLockedError. Diese hierachien sind das was exceptions besser machen als error codes.

Dravere

Shade Of Mine schrieb:

Dravere schrieb:

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

Garnix, da kann man keine vernünftigen hierachien einbauen und hierachien sind das was exceptions toll machen. sonst kann man ja gleich integer werfen...

ich will IOError fangen können oder aber BadBlockError oder FileLockedError. Diese hierachien sind das was exceptions besser machen als error codes.

Schau dir meinen Vorschlag nochmals an. Du kannst immer noch Hierarchien aufbauen und es ist nicht das gleiche, wie wenn du einen Integer wirfst, da man bei mir unterschiedliche Typen hat.

Grüssli

Shade Of Mine

Badestrand schrieb:

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

Ich verstehe den Post aber nicht.
Warum sollte keiner aufräumen können? das string objekt hat ownership, im dtor wird aufgeräumt.

es wirkt so als denkst du, dass du mit &str[0] einen zeiger auf den string bekommen könntest, und das ist halt falsch...

oder willst du was anderes sagen?

Shade Of Mine

Dravere schrieb:

Schau dir meinen Vorschlag nochmals an. Du kannst immer noch Hierarchien aufbauen und es ist nicht das gleiche, wie wenn du einen Integer wirfst, da man bei mir unterschiedliche Typen hat.

Und wie baut man hierachien auf?

das einfachste ist der präprozessor, wenn man keine IDE verwendet die das für einen macht:

IMPLEMENT_EXCEPTION_2(BadBlockError, IOException, "Bad Block at "<<param1<<" in "<<param2);

und das wird zu:

class BadBlockError : public IOException {
private:
  string msg;
public:
  template<typename Param1, typename Param2>
  BadBlockError(Param1 param1, Param2 param2)
  : msg(build_error_message(param1, param2) {
  }

  template<typename Param1, typename Param2>
  static string build_error_message(Param1 param1, Param2 param2) {
    stringstream s;
    s<<"Bad Block at "<<param1<<" in "<<param2;
    return s.str();
  }
//... what(), etc.
};

Das hat zB auch den vorteil dass ich jederzeit und überall eine neue exception klasse anlegen kann - während man bei deiner methode sich sehr schwer tut, da es zu kollisionen kommen kann.

idR ist so ein zähl template unbrauchbar...

Dravere

Shade Of Mine schrieb:

Und wie baut man hierachien auf?

In dem man neue Klassen erstellt? Bei mir ging es nur um gleiche Exceptions, also auch in der gleichen Hierarchiestufe, zusammen zu fassen, bzw. die Schreibarbeit dafür zu minimieren. Ich will nicht alle Exceptions durch die BasicExceptionWithMessage ersetzen.

Deine Möglichkeit mit dem Makro dagegen, ist natürlich etwas weiterentwickelt. So extrem viel wollte ich gar nicht vereinfachen. Allerdings die folgende Aussage, finde ich nicht ganz korrekt.

Shade Of Mine schrieb:

... während man bei deiner methode sich sehr schwer tut, da es zu kollisionen kommen kann.

Auch bei deiner Lösung mit dem Makro musst du aufpassen, da kann es ebenfalls schnell zu einer Kollision kommen. Kollisionen sind immer möglich, mit ein paar Tricks kann man sie aber verhindern, auch bei meiner Lösungsmöglichkeit.

Shade Of Mine schrieb:

idR ist so ein zähl template unbrauchbar...

Sie haben durchaus ihren Einsatzzweck.

Grüssli

Xebov

Also ich muß sagen ich bevorzuge auch die Klassen, ohne typedefs.

Das ganze ist einfach Sauberer, übersichtlicher, man kann es gut erweietrn, und vor allem man braucht oft gerademal nen Konstruktor und an dem schreibt sich keiner Tot.

also ich würde ja gern auch die Art und Weise von Shade und seinem code verstehen doch verstehe ich ihn nicht .... was ist denn das hier:

IMPLEMENT_EXCEPTION_2(BadBlockError, IOException, "Bad Block at "<<param1<<" in "<<param2);

irgendwie ein Makro? Und was macht es?

Dravere

gambo schrieb:

irgendwie ein Makro? Und was macht es?

Hat Shade Of Mine doch gesagt, es erzeugt den gezeigten Code. Und Shade Of Mine hat auch gesagt, dass es eine Präprozessor Anweisung ist, also ein Makro. Lies einfach nochmals den Beitrag

Grüssli

MIch würd mal interessieren was ihr so in die exceptions reinpackt dass sie so unterschiedliche werden...ich bin sehr blauäugig und kann mir im moment nur vorstellen dass da sowieso doch nur ein string steht der geworfen wird oder nicht? Was macht ihr mit File-Exceptions oder anderen?

Danke

Xebov

In meinen ist auch nur ein string drin. Grundsätzlich ist eine Exception-Klasse aber eine normale Klasse, dh sie kann alles aufnehmen was immer du ihr mitgeben willst, zB kannst du ihr Momentaufnahmen von Variablen mitgeben. Es gab auchmal den Ansatz in nem Anderen Thread ne Exception bei sehr tiefen Strukturen zum Transport des Rückgabewertes zu benutzen.