Wozu assignment operator exception safe machen?
-
Ich weiß um was es geht. Ich suche einen realen Anwendungsfall und nicht ein nichtssagendes Codestück.
-
butterbeidiefische schrieb:
Ich weiß um was es geht. Ich suche einen realen Anwendungsfall und nicht ein nichtssagendes Codestück.Jedesmal wenn eine variable laenger existiert als der try block.
zB weil die zielvariable ein out parameter der funktion ist oder aber die variable member einer klasse ist, etc. Ich koennte jetzt eine Million Beispiele liefern, aber sie sind alle konstruiert und werden dir deshalb nicht gefallen.das problem ist naemlich, dass die frage falsch ist.
-
butterbeidiefische schrieb:
Ich weiß um was es geht. Ich suche einen realen Anwendungsfall und nicht ein nichtssagendes Codestück.Was heißt nichts sagend, das Beispiel von Volkhard ist genau das worum es geht. Ich geb dir ein konkretes Beispiel das ich selbst hier habe. Du hast eine Klasse die aus verschiedenen Zeigern und Variablen besteht. Nun willst du eine Zuweisung machen, nun gibt es genau 2 Möglichkeiten, entweder die zuweisung klappt, oder unterwegs geht was Schief. Wenn etwas schief geht ist deine Zuweisung fehelrhaft und das Objekt auf das du zugewiesen hast ist für die Tonne weil du nicht weist wie weit es mit gültigen Daten gefüttert wurde. Genau dafür ist die Exceptionsicherheit, denn sie garantiert das Fall 2 nie eintritt, es können genau 2 Möglichkeiten bei exceptionsicherheit rauskommen, das Objekt ist ok, oder es flog eine Exception und das Objekt wurde zurückgesetzt und ist damit unverändert, dh also das Objekt ist so oder so brauchbar, schöner nebeneffekt du erfährst was schiefgegangen ist.
Seit mich Shade, Devere und Nexus von Exceptions überzeugt haben arbeite ich nurnoch damit und es is echt ne praktische Sache.
-
Was ist den ein Anwendungsfall bei dem bei der Zuweisung eine Exception fliegt und es dann noch sinnvoll ist weiter zu machen, als ob nichts gewesen wäre? Wenn ich mit einem Objekt was machen will, dann will ich doch das Ergebnis auch haben und nicht nach einem catch weiter machen als ob das Ergebnis zugewiesen wurde, obwohl es vielleicht garnicht zugewiesen wurde.
Shade Of Mine schrieb:
das problem ist naemlich, dass die frage falsch ist.
Was wäre die richtige Frage?
-
butterbeidiefische schrieb:
Was ist den ein Anwendungsfall bei dem bei der Zuweisung eine Exception fliegt und es dann noch sinnvoll ist weiter zu machen, als ob nichts gewesen wäre? Wenn ich mit einem Objekt was machen will, dann will ich doch das Ergebnis auch haben und nicht nach einem catch weiter machen als ob das Ergebnis zugewiesen wurde, obwohl es vielleicht garnicht zugewiesen wurde.
Shade Of Mine schrieb:
das problem ist naemlich, dass die frage falsch ist.
Was wäre die richtige Frage?
Du musst nicht weitermachen, als ob nichts gewesen wäre. Du kannst z.B etwas anderes versuchen. Z.b fliegt eine exception, weil nicht genug Speicher da ist. Also kannst du das abfangen und versuchen genug Speicher frei zu geben. In dem du z.b irgendwelche unbenötigten Ressourcen kickts und dann versuchst du es erneut.
-
Ja, und wozu muss dann der Zustand des Objekts gültig sein, wenn ich es sowieso wieder überschreiben will?
-
Ist das Objekt in einem ungültigen Zustand, wird jede Operation undefiniert sein und kann zum Absturz führen. Jetzt sagst du: Aber ich rufe dann eben keine Methoden mehr auf. Das geht aber nicht. Mindestens eine Methode wird noch ausgeführt: Der Destruktor. Spätestens da erzeugst du im besten Fall Memoryleaks im schlechtesten Fall könntest du ne Datenbank zerschießen (Der Kunde wird sich freuen).
Gruß
Don06
-
Ein Memleak hast du, wenn du bei Zuweisen was nicht richtig frei gibst, aber das geht unabhängig von Exceptionsafety. Das mit der Datenbank ist sehr unrealistisch. Normal hast du am Ende ein commit oder rollback, dass es danach noch ein Objekt gibt das im Destruktor in die DB schreibt, wäre schon sehr ausergewöhnlich. Wozu auch?
-
butterbeidiefische schrieb:
Das mit der Datenbank ist sehr unrealistisch.
Im Prinzip nicht, da du das rollback/commit ja idR im destruktor machst
Sprich das rollback/commit ist undefiniert.Boese Sache sowas.
Natuerlich geht es in 99% aller Faelle gut. Keine Frage. Aber bei irgendwem tritt das letzte Prozent auf...
-
Wenn du das rollback per RAII/RRID im Destruktor machst, dann ist es aber unrealistisch, dass diesem "Rollback-Objekt" zwischendurch was anderes zugewiesen wird. Du tauscht ja auch nicht den Filestream aus, während du reinschreibst.
-
Zum Thema:
http://www.gotw.ca/gotw/059.htm