Exceptions im Destruktor
-
Okay, das war auch meine Vermutung. Im Internet liest man halt oft never throw an exception from a destructor, aber es steht nie dabei, dass es okay ist, wenn man sie auch noch im Destruktor fängt.
Ich wollte nur 100% sichergehen
-
"Never throw an exception from a destructor". Wenn du sie drinnen fängst, dann fliegt sie ja eben nicht raus!? Wie gesagt würd ich persönlich aber ganz sicher erstmal mein Design hinterfragen, wenn ich mich wirklich in der Situation finden würde, dass ich gerade einen try Block in einen Destruktor schreiben will...
-
dot schrieb:
Michael E. schrieb:
Denn sobald man einen Destruktor braucht, ist auch häufig eine Operation dabei, die eine Exception werfen kann.
Ich würde mal meinen, dass sowas doch eher sehr selten der Fall ist. Wenn ich sowas bauen will, würd ich wohl erstmal sehr ernsthaft drüber nachdenken, was ich da denn grad im Begriff bin zu tun, dass beim Aufräumen was schieflaufen kann und ob sowas wirklich in einem Desktruktor sein sollte...
Dies könnte z.B. eine Hardware-Ressource sein, welche recht umfangreich de-initialisiert wird, und das ist halt evtl. nicht mehr möglich, wenn sich das Gerät verabschiedet hat.
-
dot schrieb:
"Never throw an exception from a destructor". Wenn du sie drinnen fängst, dann fliegt sie ja eben nicht raus!?
Das "from" hab ich schon gelesen - aber die Formulierung war mir nicht explizit genug.
-
berndbernd schrieb:
dot schrieb:
Michael E. schrieb:
Denn sobald man einen Destruktor braucht, ist auch häufig eine Operation dabei, die eine Exception werfen kann.
Ich würde mal meinen, dass sowas doch eher sehr selten der Fall ist. Wenn ich sowas bauen will, würd ich wohl erstmal sehr ernsthaft drüber nachdenken, was ich da denn grad im Begriff bin zu tun, dass beim Aufräumen was schieflaufen kann und ob sowas wirklich in einem Desktruktor sein sollte...
Dies könnte z.B. eine Hardware-Ressource sein, welche recht umfangreich de-initialisiert wird, und das ist halt evtl. nicht mehr möglich, wenn sich das Gerät verabschiedet hat.
Gut, das wäre eine Möglichkeit. Als den häufigen Regelfall würd ich sowas aber eher nicht bezeichnen
-
Die genaue Formulierung im Standard ist wie folgt (auf relevante Stellen zusammengekürzt):
ISO/IEC 14882:2003 15.5.1 (1) schrieb:
In the following situations exception handling must be abandoned for less subtle error handling techniques:
(...)
— when the destruction of an object during stack unwinding (15.2) exits using an exception, or
(...)
Hervorhebung von mir. Das bedeutet, dass der Destruktor machen kann, was er will, solange das, was im Destruktor passiert, im Destruktor bleibt. Ich schlage vor, das die Las-Vegas-Regel zu nennen.
-
in der aktuellen auflage von effektiv c++ von scotti meyers steht dazu in kapitel 2.4 Tipp 8:
und zwar wie du richtig sagtest, exceptions die in einemd estruktor geworfen werden sind böse.
weiter schlägt er natürlich lösungsansätze voralle lösungsansätze werden gefangen und dazu wird ein logbuch eintrag gemacht oder das programm wird beendet (std::abort). ist aber beides nicht gut meint er dazu (würde ich rein intuitiv auch sagen, dass da keiner mehr kontrolle hat). also lösung schlägt er vor, dass mand er klasse eine methode gibt, die aufräumt und auch eine exception werfen kann. dazu gibt man der klasse noch eine boolsche membervariable, die angibt ob schon aufgeräumt wurde oder nicht. und für den fall dass im destruktor noch nicht aufgeräumt wurde, wird halt die clear methode aufgerufen und alle exceptions werden verschluckt und vllt noch protokolliert. aber im endeffekt hat der user selbst die kontrolle mit den exceptions indem er die clear methode aufrufen kann...
-
dot schrieb:
Gut, das wäre eine Möglichkeit. Als den häufigen Regelfall würd ich sowas aber eher nicht bezeichnen
Naja, wie häufig schreibst du denn Destruktoren?
-
Michael E. schrieb:
dot schrieb:
Gut, das wäre eine Möglichkeit. Als den häufigen Regelfall würd ich sowas aber eher nicht bezeichnen
Naja, wie häufig schreibst du denn Destruktoren?
am liebsten gar nicht
am liebsten nutz ich keinen dynamsichen speicher und keine pointer frickeleien und lasse das alles automatisch machen (smart pointer, vector usw)
-
Michael E. schrieb:
dot schrieb:
Gut, das wäre eine Möglichkeit. Als den häufigen Regelfall würd ich sowas aber eher nicht bezeichnen
Naja, wie häufig schreibst du denn Destruktoren?
Ziemlich oft. Aber dass ich mal nen Destruktor mit nem try-Block drin geschrieben hätte, daran kann ich mich nicht erinnern...
-
dot schrieb:
Michael E. schrieb:
Naja, wie häufig schreibst du denn Destruktoren?
Ziemlich oft.
In welchem Umfeld entwickelst du? Wie sieht ein typischer Destruktor aus?
-
Michael E. schrieb:
In welchem Umfeld entwickelst du?
Hauptsächlich Grafikprogrammierung.
Michael E. schrieb:
Wie sieht ein typischer Destruktor aus?
z.B. so:
~Scene() {}
-
Gnarf, Default-Destruktoren, die man nur schreibt, um sie virtuell zu machen, zählen nicht
-
Michael E. schrieb:
Gnarf, Default-Destruktoren, die man nur schreibt, um sie virtuell zu machen, zählen nicht
Aber der ist gar nicht virtuell. Aber gut, ich hab ihn geschrieben, um ihn protected zu machen :p
