Fehlertoleranz DELPHI Compiler

[mkinzler]

Das Problem schient so wichtig zu sein, dass man es hier paralell in mehreren Threads diskutiert!

[Stevie]

Zitat von mkinzler:

Das Problem schient so wichtig zu sein, dass man es hier paralell in mehreren Threads diskutiert!

Welches sind die anderen Threads zu diesem Thema?

[himitsu]

Zitat von Stevie:

Welches sind die anderen Threads zu diesem Thema?

Den hatte ich hier vorhin sogar extra verlinkt.

[add] Post #22

[Stevie]

Zitat von himitsu:

Zitat von Stevie:

Welches sind die anderen Threads zu diesem Thema?

Den hatte ich hier vorhin sogar extra verlinkt.

[add] Post #22

Ach das Thema meint er - ja, sind durchaus themenverwandt aber vom OP aus verschieden.

P.S. Wobei das Problem bei ARC nicht aufgetreten wäre

[mkinzler]

Das mit der GC Problematik meinte ich. Aber meine Meinung ist ja nicht relevant.

[Meflin]

Zitat von Patito:

Ist sie nicht. Stell Dir mal vor Du hast ein Objekt, das eine Bestellung von 100 Tonnen
nassem Beton repräsentiert - der in deinen Vorgarten gekippt werden soll.

Jetzt willst Du dieses Objekt löschen - und alle Zugriffe auf das Objekt sollen
zu Fehlern führen. Mit GC ist das ein Krampf - man muss da quasi händisch das Rad der
Access Violation neu erfinden.

Diese Denkweise ist so falsch, dass ich gar nicht weiß, wo ich anfangen soll. Warum um alles in der Welt würde man die Speicherverwaltung für Geschäftslogik missbrauchen?! Es ist doch in keinem realen Softwaresystem so, dass, um beim Beispiel zu bleiben, eine abgebrochene Bestellung tatsächlich aus dem System gelöscht würde. Nein, natürlich wird die als abgebrochen markiert und verbleibt im System. Und will man dann doch einen Datensatz tatsächlich löschen, hat das ja wiederum absolut nichts mit Garbage Collection zu tun. Das sind doch hier Abstraktionsebenen, die du vermischt, die absolut nichts miteinander zu tun haben!

Mir scheint hier irgendwie teilweise das Bild vorzuherrschen, Garbage Collectors wären dazu da, schlechten Programmierstil zu kaschieren oder ähnliches und mit genügend "Skill" hätte man soetwas nicht nötig. Das ist, gelinde gesagt, völliger Schwachsinn.

[Stevie]

Zitat von Meflin:

Mir scheint hier irgendwie teilweise das Bild vorzuherrschen, Garbage Collectors wären dazu da, schlechten Programmierstil zu kaschieren oder ähnliches und mit genügend "Skill" hätte man soetwas nicht nötig. Das ist, gelinde gesagt, völliger Schwachsinn.

Das sicherlich nicht, aber mit einem GC brauch ich mir keine Sorge machen, dass ein Objekt a) nach Benutzung nicht freigegeben wird oder dass es b) vorzeitig freigegeben wird. Ich habe dort kein verantwortliches "Besitzer" Objekt, welches sich darum kümmert oder diese Verantwortlichkeit weitergibt. Das wiederum habe ich aber in Delphi und es ist nicht immer einfach, das zu überblicken und verwalten. Jeder, der schonmal mit Listen gearbeitet hat, von denen eine OwnsObjects True hat und dann Objekte von einer Liste in eine andere schiebt oder kopiert, wird wissen, dass es in einen Albtraum ausarten kann, sich durch EAccessViolation und/oder EInvalidPointer Exceptions zu kämpfen.

[stahli]

Vielleicht können wir uns darauf einigen, dass es um vergessene Referenzen auf aufgelöste Objekt(speicherplätz)e geht.
Solche Zugriffe sollten sowohl von der BL als auch von der GUI vermieden werden.

Dennoch kann es vorkommen, insbesondere bei der Entwicklung eines komplexen Projektes. Man braucht ja nur den Owner aufzulösen und vergisst, dass das Objekt diesem zugeordnet ist.

Schön wäre es, wenn alle Referenzen auf ein Objekt bei dessen Auflösung automatisch genilt würden, aber das wird auch in Zukunft nicht realisierbar sein. Mit Assign(Referenz) könnte man immer auf die Existenz des Objektes prüfen.

Die Objektreferenz noch am Leben zu erhalten und damit auf fragwürdige Daten zuzugreifen finde ich eigentlich nicht optimal. Es hat eben Vor- und Nachteile. Sofern man mit den Daten nix weiter anstellt, ist das für das Projekt nicht weiter schädlich. Wenn die Existenz des Objektes aber mein übriges Projekt beeinflusst, dann ist das natürlich schlecht.

Also sollte man ein Objekt vor dem Auflösen "disablen", so können vergessene Referenzen erkennen, dass das Objekt, auf welches sie zeigen eigentlich nicht mehr da ist.

Ein prakisches Beispiel ist Windows: Führt man in einem Control ein Schließen seines ParentForms durch, erhält dieses Control evtl. zuvor noch den Focus. Winndows will das Control kurz darauf schön focussiert zeichnen.
Form und Control sind nicht mehr da - es knallt. (Das hängt wohl tatsächlich mit den Handels zusammen, ist aber ein anschauliches Beispiel.)

[Patito]

Zitat von Meflin:

Zitat von Patito:

Ist sie nicht. Stell Dir mal vor Du hast ein Objekt, das eine Bestellung von 100 Tonnen
nassem Beton repräsentiert - der in deinen Vorgarten gekippt werden soll.

Jetzt willst Du dieses Objekt löschen - und alle Zugriffe auf das Objekt sollen
zu Fehlern führen. Mit GC ist das ein Krampf - man muss da quasi händisch das Rad der
Access Violation neu erfinden.

Diese Denkweise ist so falsch, dass ich gar nicht weiß, wo ich anfangen soll.

Erst heißt es ein GC löst magisch alle Zugriffsprobleme auf ungültige Objekte.
Dann gibt es auf einmal in Programmen überhaupt keine Notwendigkeit mehr auf
Zugriffe auf ungültige Objekte überhaupt zu testen "wegen der Geschäftslogik
in realen Softwaresystem".

Als nächstes kommt ihr noch auf die Idee und schreibt für C# einen Meta-GC, der verhindert, dass dort
Weak-References jemals auf ungültige Targets verweisen können...

Comedy vom feinsten...

[himitsu]

Ab TComponent könnte man aber schon seit Jahrzehnten Listen erstellen (hat nur noch keiner gemacht), wo die Referenzen automatisch entfernt werden, wenn jemand Anderes (z.B. der Owner) das Objekt freigibt.

Also ab TComponent ist dieses Feature drin, wenn man es nicht selber implementieren will. Dieses wird z.B. für die ganzen (Kreuz)Verlinkungen ala Parent-Child und Owner-Owned verwendet.