Fehlertoleranz DELPHI Compiler

**stahli**

@ Stahli :
mit eigentlich ungültigen Werte noch arbeiten zu können halte ich für nicht sehr geschickt, man sollte das Problem an der Wurzel packen und auch dort sofort beheben.

Das Problem liegt halt in der EDV.
Wenn ein Dritter mein Fahrrad klaut kann ich mich am nächsten Tag nicht mehr drauf setzen.

Wenn irgendwer mein Objekt zerstört, dann sind die Speicherzellen halt ja noch dort und irgendwelche Zeiger können auf die Stelle verweisen.
Eine vollständig automatische Zeigerbereinigung ist undenkbar - nicht mal für mich!

Aber wenn ich dem Compiler sagen könnte: "Richte mal für mich eine Überwachung meines Fahrrades ein und setze F1 und F2 auf null, wenn das Fahrrad aufgelöst wird.", das wäre schon eine nette Sache und würde dem Programmierer eigene Obser-Lösungen oftmals abnehmen können.
Natürlich hilft das Konstrukt auch nur dann, wenn das Fahrrad regulär freigegeben wird, aber nicht, wenn eine Walze drüber fährt (bzw. der Speicher irgendwie fehlerhaft überschrieben wird).

**Stevie**

Klassischer Fall von Objekt über seine lifetime hinaus benutzt.

Will man dem entgehen, muss man entweder genau Herr darüber sein, wann wer was frei gibt oder man wendet sich einer GC Sprache zu, da kann man anders rumfuhrwerken.

In deinem konkreten Fall würde ich aber eher ein Architektur Problem vermuten, da dein TForm2 das TDataClass Objekt erzeugt, während TForm1 das scheinbar nicht macht. Wenn doch, dann hast du an der gezeigten Stelle nicht nur einen dangling Pointer sondern auch ein Memory leak. An dieser Stelle steht dann die Entscheidung, ob du exakt dieselbe Instanz brauchst, oder ob dort ein Assign Aufruf reicht, um bloß den State von dem einen TDataClass Objekt ins andere zu schieben.

**Patito**

Zitat von Stevie:

Klassischer Fall von Objekt über seine lifetime hinaus benutzt.

Will man dem entgehen, muss man entweder genau Herr darüber sein, wann wer was frei gibt oder man wendet sich einer GC Sprache zu, da kann man anders rumfuhrwerken.

Verbirgt sich dahinter eigentlich praktische Technik, oder liegt hier die Betonung eher auf "rumfuhrwerken"??

**Stevie**

Zitat von Patito:

Zitat von Stevie:

Klassischer Fall von Objekt über seine lifetime hinaus benutzt.

Will man dem entgehen, muss man entweder genau Herr darüber sein, wann wer was frei gibt oder man wendet sich einer GC Sprache zu, da kann man anders rumfuhrwerken.

Verbirgt sich dahinter eigentlich praktische Technik, oder liegt hier die Betonung eher auf "rumfuhrwerken"??

Ich meinte damit, dass man sich dort (bis auf Ausnahmen) keinen Kopf um Speicherverwaltung machen muss - was ich hier nicht bewerten möchte, da es sowohl Vor- als auch Nachteile mit sich bringt.

Zitat von jaenicke:

Oder man benutzt einfach konsequent das oben bereits genannte FreeAndNil, dann knallt es auch direkt, es sei denn es handelt sich um eine lokale (und daher nicht automatisch initialisierte) Variable.

Einziger Fallstrick dabei ist, wenn man den Code später auf Interfaces umstellt. An FreeAndNil kann man nämlich auch Interfaces übergeben, deshalb knallt es leider erst beim Aufruf.

FreeAndNil (am besten noch mit ganz vielen if Assigned(...) garniert) kaschiert nur noch mehr eine mögliche Ahnungslosigkeit, wer für diese Instanz eigentlich zuständig ist.
Aber lasst uns die FreeAndNil Diskussion gleich wieder begraben, das hatten wir schon

an anderer Stelle zu genüge

Zitat von Stevie:

FreeAndNil (am besten noch mit ganz vielen if Assigned(...) garniert) kaschiert nur noch mehr eine mögliche Ahnungslosigkeit, wer für diese Instanz eigentlich zuständig ist.

Sehr schön erklärt.

Wem gehört die Instanz? Wir haben es hier mit einem globalen Objekt zu tun, quasi ein Singleton, der seine Singularität durch das Kopieren der Instanz erhält. Wir wissen, das so etwas ziemlich 'böse' ist (eigentlich ist es nur ein sehr wackeliges Design) und mit Samthandschuhen anzufassen, ach was rede ich, komplett zu vermeiden ist.

Wozu gibt es in Delphi das Konzept der Datenmodule? Die sind ja nicht auf TDataSets beschränkt. Das Konzept ist 25 Jahre alt (soweit ich mich erinnere) und sollte vermeiden, das Daten wüst hin und her verschoben und übergeben werden.

Letztendlich verwaltet dann ein Datenmodul die DataClass-Instanz, erzeugt sie und gibt sie wieder frei. Es muss -per Architektur- einfach wissen, wann es sich verabschieden darf.

Und wenn man dann auch noch damit aufhört, Objektinstanzen zu kopieren, sondern nur als Parameter zu übergeben, kann der beschriebene Bug (der ja keiner is) gar nicht auftreten.

**Patito**

Zitat von Stevie:

Ich meinte damit, dass man sich dort (bis auf Ausnahmen) keinen Kopf um Speicherverwaltung machen muss - was ich hier nicht bewerten möchte, da es sowohl Vor- als auch Nachteile mit sich bringt.

Um Speicherverwaltung direkt nicht. Aber das eigentliche praktische Problem ist doch, dass man Zugriffe auf bereits entsorgte Objekte verhindern möchte. Da hilft einem der GC gar nicht - bzw. dort ist einfach alles erlaubt.

Ich sehe den Vorteil eher auf der nicht-GC Seite. Dort kann man konkret testen und debuggen.
Während mit GC einfach jedes tote Objekt lustig weiter verwendet werden kann.

Dieses "sich keinen Kopf machen müssen" mit GC halte ich für eine reichlich naive Sichtweise.

**himitsu**

Zitat von Patito:

Dieses "sich keinen Kopf machen müssen" mit GC halte ich für eine reichlich naive Sichtweise.

Siehe meine Signatur.

Aber stimmt ... noch ein Grund, warum der "Probleme" bereiten kann.

Und die hatte ich sogar schon lange bevor das hier auftauchte:

http://www.delphipraxis.net/171824-g...i-objekte.html

**Medium**

Ein GC räumt erst dann Objekte weg, wenn alle Referenzen die auf sie verweisen aus ihrem Scope fallen. Zugriffe auf Referenzen die nicht im Scope liegen, sind schon durch den simplen Syntax-Check abgedeckt.

**Meflin**

Zitat von Patito:

Ich sehe den Vorteil eher auf der nicht-GC Seite. Dort kann man konkret testen und debuggen.
Während mit GC einfach jedes tote Objekt lustig weiter verwendet werden kann.

Die Aussage ist ja in sich schon widersprüchlich; entweder ein Objekt wird noch verwendet, dann kann es aber nicht gleichzeitig tot sein. Oder aber es wird nicht mehr verwendet, dann wird es der GC auch wegräumen

Ganz im Gegenteil, das Beispiel aus dem Eingangspost zeigt doch sehr schön, dass man derartige Probleme aber bei manueller Speicherverwaltung sehr wohl haben kann. Mit Garbage Collection aber halt schlicht und ergreifend nicht. Und wie du darauf kommst, mit GC liese sich schlechter Debuggen oder Testen, das würde mich ja mal interessieren...

**stahli**

Zitat von Meflin:

Die Aussage ist ja in sich schon widersprüchlich; entweder ein Objekt wird noch verwendet, dann kann es aber nicht gleichzeitig tot sein. Oder aber es wird nicht mehr verwendet, dann wird es der GC auch wegräumen

Das Objekt ist tot, wenn es von der "zuständigen Stelle" freigegeben wird.
Ab dann sind Zugriffe auf das Objekt von anderer Stelle aus (Referenzen) darauf grundsätzlich fehlerhaft.
Entweder werden
a) vor kurzem noch korrekte Daten benutzt, die inzwischen aber im Projektkontext keine Gültigkeit mehr haben
b) komplett ungültige Daten benutzt, weil die Speicherstellen inzwischen überschrieben wurden
c) knallt es weil Methoden auf Grund eines überschriebenen Speichers nicht mehr ausführbar sind

Ein GC sichert ab, dass nur Problem a) entsteht. Aber eine ausreichende Lösung ist das noch nicht.
Im Spiel könnte so noch auf das Raumschiff zugeriffen werden, obwohl es eigentlich schon explodiert ist. Jetzt kann man streiten ob das besser ist als eine Exception.