Exception werfen

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.

pumuckl

Xebov schrieb:

Es gab auchmal den Ansatz in nem Anderen Thread ne Exception bei sehr tiefen Strukturen zum Transport des Rückgabewertes zu benutzen.

Was aber wider den Zweck von Exceptions gehen würde. Exceptions sind zur Fehlerbehandlung da und nicht, um Funktionsergebnisse durch die Gegend zu schmeißen nach dem Motto "Fang doch wenn dus wissen willst".

Shade Of Mine

Dravere schrieb:

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.

Na dann erklär mal wie es bei meiner variante zu kollisionen kommen kann und wie du sie bei deiner verhindern kannst.

Xebov

pumuckl schrieb:

Xebov schrieb:

Es gab auchmal den Ansatz in nem Anderen Thread ne Exception bei sehr tiefen Strukturen zum Transport des Rückgabewertes zu benutzen.

Was aber wider den Zweck von Exceptions gehen würde. Exceptions sind zur Fehlerbehandlung da und nicht, um Funktionsergebnisse durch die Gegend zu schmeißen nach dem Motto "Fang doch wenn dus wissen willst".

Naja ich wollte es ja nur erwähnen, ich glaub Konkret gings dabei um einen sehr tiefen Baum und die Idee das eien Exception mit dem Ergebniss schnelelr wäre als es über die ganzen Returns durchzureichen. Aber wie gesagt ich wolte es nur als Beispiel erwähnen.

Dravere

Shade Of Mine schrieb:

Na dann erklär mal wie es bei meiner variante zu kollisionen kommen kann ...

Du definierst den gleichen Namen in unterschiedlichen Übersetzungseinheiten. Könnte ich mir gut vorstellen, wenn die Sache ein wenig grösser wird und man so ein Makro zur Hand hat, welches mal schnell und einfach eine neue Exception erzeugt. Da man bei einem grösseren Projekt wohl eher seltener linkt, taucht der Fehler wohl auch erst später auf. Klar, man kann ihn sicher sehr schnell beheben

Shade Of Mine schrieb:

... und wie du sie bei deiner verhindern kannst.

Wie ich schon sagte, würde ich sowas nur bei seeeeehr gleichen Exceptions verwenden. Also alle in der gleichen Hierarchiestufe und für den selben Bereich. Das werden wohl kaum mal mehr als 5 Exceptionklassen sein. Diese gemeinsamen Klassen würde ich durch ein Template vereinigen, um Schreibarbeit zu sparen und wahrscheinlich, gleich in den gleichen Header packen. Also ist alles beieinander.
Nur nochmals zur Sicherstellung, dass dies rüberkam: Eine andere Stufe, eine andere Gruppe, eine andere Schablone. Die gleiche Schablone nutzen immer nur ein paar wenige. So spart man sich eben ein paar Duzend Zeilen und über Snippets von VAX kann ich mir jeweils eine Schablone erstellen lassen.

Gemacht habe ich es noch nie, war nur eine Überlegung, aber so schlecht finde ich sie nicht. Wobei ich sagen muss, dass deine Methode auch was hat. Derzeit war ich aber noch nicht faul genug, bzw. die Arbeit war noch nicht zu aufwendig, dass ich auf sowas zurückgreifen würde

Grüssli

Shade Of Mine

Dravere schrieb:

Du definierst den gleichen Namen in unterschiedlichen Übersetzungseinheiten. Könnte ich mir gut vorstellen, wenn die Sache ein wenig grösser wird und man so ein Makro zur Hand hat, welches mal schnell und einfach eine neue Exception erzeugt. Da man bei einem grösseren Projekt wohl eher seltener linkt, taucht der Fehler wohl auch erst später auf. Klar, man kann ihn sicher sehr schnell beheben

Äh, du definierst nur normale klassen. natürlich kannst du klassen gleich benennen, aber ist das echt eine fehlerquelle?

Dravere

Shade Of Mine schrieb:

Äh, du definierst nur normale klassen. natürlich kannst du klassen gleich benennen, aber ist das echt eine fehlerquelle?

In meinen Augen ja, weil du die Definition einer neuen Exceptionklasse so vereinfachst. Sobald man Dinge vereinfacht, denken die Leute auch nicht mehr so genau darüber nach. Sicher, der Fehler ist nicht schlimm und wohl auch schnell behoben.

Grüssli

Shade Of Mine

Dravere schrieb:

In meinen Augen ja, weil du die Definition einer neuen Exceptionklasse so vereinfachst. Sobald man Dinge vereinfacht, denken die Leute auch nicht mehr so genau darüber nach. Sicher, der Fehler ist nicht schlimm und wohl auch schnell behoben.

Selbes gilt für Variablen, Funktionen, etc.
Das macht keinen Sinn. Doppelte Klassen anlegen zu können ist keine relevante Fehlerquelle.