AV innerhalb des if-Statements lässt sich nicht abfangen

[uups]

Hallo!

Ich habe eine etwas längere if-Statement bestehend aus mehreren Dutzend ANDs und ORs, die allesamt auf ein bestimmtes Object zugreifen. Wird dieses bestimmtes Object freigegeben, während IF gerade diese ANDs und ORs durläuft, erscheinen mehrere AV nacheinander, die sich mit TRY..EXECPT..END nicht abfangen lassen. Kann ich was dagegen tun?

Danke!

[Luckie]

Ja. Gib dss Objekt nicht frei, wenn noch darauf zugegriffen wird oder noch werden soll. Oder sorg dafür das der if Block verlassen wird, wenn das Objekt freigegeben wird.

[uups]

Zitat:

Zitat von Luckie (Beitrag 1386017)

Ja. Gib dss Objekt nicht frei, wenn noch darauf zugegriffen wird...

Wie kann ich prüfen, on auf ein Object gerade zugegriffen wird?

[Glados]

Zitat:

Ich habe eine etwas längere if-Statement bestehend aus mehreren Dutzend ANDs und ORs

Ich würde hier ansetzen und das erst einmal aufteilen.

[Dalai]

Zitat:

Zitat von uups (Beitrag 1386018)

Wie kann ich prüfen, on auf ein Object gerade zugegriffen wird?

Den Code durchschauen? Du musst doch wissen, wo dein Code auf das Objekt zugreift. If-Bedingungen sollten eigentlich nie irgendeine Aktion ausführen, schon gar nicht ein Objekt freigeben.

Und im übrigen stimme ich Glados zu: Mehrere Dutzend Einzelbedingungen - also mehr als 24 Stück - in einem einzelnen If-Statement? Schon ab drei oder vier wird's (total) unübersichtlich.

Grüße
Dalai

[ibp]

wir wirklich während der Prüfung innerhalb einer If Abfrage gelöscht?

Wenn nicht, vorher mal mit

Delphi-Quellcode:

if Assigned(meinObjekt) then

prüfen ob das noch vorhanden ist.

[Luckie]

Das ist aber in diesem Fall nur eine Krücke und keine Lösung für das eigentliche Problem. Ich meine, er zieht sich ja selbst den Teppich unter den Füßen weg. Und wenn ich es selbst mache, muss ich danach nicht noch mal gucken, ob der Teppich noch da ist. :cyclops:

[p80286]

Zitat:

Zitat von Luckie (Beitrag 1386065)

Ich meine, er zieht sich ja selbst den Teppich unter den Füßen weg.

Nee das macht sein Programm, und plötzlich und unerwartet fehlt da was.
Und selbst wenn es so wäre, irgendwie müßte ja theoretisch das Fehlen eines Wertes/Objektes mit einkalkuliert sein.

Gruß
K-H

[Luckie]

Zitat:

Zitat von p80286 (Beitrag 1386072)

Zitat:

Zitat von Luckie (Beitrag 1386065)

Ich meine, er zieht sich ja selbst den Teppich unter den Füßen weg.

Nee das macht sein Programm,

Und wer hat das Programm geschrieben? Und da ist auch nicht plötzlich und unerwartet was weg. Er hat es so programmiert, dass es weg ist. Es heißt doch immer so schön: "Das Programm macht nicht, was du willst, sondern was du programmierst."

[MichaelT]

Mit Verlaub, das hört sich seltsam an. Code?

Einfache Sache, wird aber auch nicht wirklich zutreffend sein, wäre sofern die Referenz auf nil gesetzt, dass ist die Kurzschlussauswertung abgedreht ist.

{$B+} or {$B-} {$BOOLEVAL ON} or {$BOOLEVAL OFF}

Delphi-Quellcode:

If Assigned(poidl) AND ((poidl.Alter < 12) OR (poidl.IsBlunzenFett)) then ....

funktioniert dann auch nicht mehr, auch wenn der poidl NIL ist.

Vermutlich kommt aber der Zeiger mit einer gesetzten ungültigen Adresse daher oder Methoden greifen auf uninitalisierte Objekte zu usw...

Zitat:

Zitat von uups (Beitrag 1386016)

Hallo!

Ich habe eine etwas längere if-Statement bestehend aus mehreren Dutzend ANDs und ORs, die allesamt auf ein bestimmtes Object zugreifen. Wird dieses bestimmtes Object freigegeben, während IF gerade diese ANDs und ORs durläuft, erscheinen mehrere AV nacheinander, die sich mit TRY..EXECPT..END nicht abfangen lassen. Kann ich was dagegen tun?

Danke!

[Zacherl]

Wahrscheinlich macht er sowas in der Art:

Delphi-Quellcode:

if (Obj.Foo = Bla) and (Obj.MethodeDieObjEvtlFreigibt) and (Obj.Bar = Bla) then
begin
  ...

So oder so hat Luckie recht mit seiner Aussage, dass man das Problem wohl besser an der Wurzel anpacken sollte. Klingt zumindest verdächtig nach nicht gut durchdachten Code-Design.

[TigerLilly]

Zitat:

Zitat von Zacherl (Beitrag 1386140)

Klingt zumindest verdächtig nach nicht gut durchdachten Code-Design.

Solche Wertungen tun weh, sind unsachlich + nicht hilfreich.

Ich würde eine boolsche-Variable einführen + die if-Abfrage aufdröseln:

Code:

bTest:=true;
if bTest then begin
  bTest:=bTest and Bedingung1;
end;
if bTest then begin
  bTest:=bTest and Bedingung2;
end;
...

Je nachdem, wie kompliziert das If ist, muss man das ev. noch verschachteln. Aber so hat man recht schnell die problematische Abfrage.

[TiGü]

Der TE hat sich zuletzt am 11. November gemeldet.
Es ist wohl müssig weitere Tipps zu geben.

[Zacherl]

Zitat:

Zitat von TigerLilly (Beitrag 1386195)

Zitat:

Zitat von Zacherl (Beitrag 1386140)

Klingt zumindest verdächtig nach nicht gut durchdachten Code-Design.

Solche Wertungen tun weh, sind unsachlich + nicht hilfreich.

Finde jetzt nicht, dass meine Vermutung abwertend oder unhöflich war und wenn sie doch so aufgenommen wurde, dann war das definitiv nicht meine Intention. Da der TE sich bisher nicht mehr gemeldet hat, sicherlich ein wenig spekulativ (aber dennoch basierend auf den vorher getätigten Aussagen).

Deshalb bleibe ich dabei:
Wenn ich mir während ich auf einem Objekt arbeite (sogar zwischen zwei Bedingungen/Funktionsaufrufen in einer Abfrage) dieses Objekt selbst unter den Füßen wegziehe, indem ich es zerstöre, dann ist das nunmal - vorsichtig ausgedrückt - kein optimales Code-Design. Sowas passiert auch (die Verwendung von Threads mal abgesehen) wirklich nur dann, wenn man nicht eindeutig definiert, wer ein Objekt "besitzt". Im Optimalfall sollte der Besitzer das Objekt sowohl erstellen, als auch nach getaner Arbeit wieder freigeben.

[Fukiszo]

bevor dein IF-block anfängt setz ein boolean auf dein objekt,
markier es.
innerhalb deines IF-block reagier auf den boolean.
der externe code der das objekt behandelt muss dann lediglich das boolean setzen.
true = objekt steht zur verfügung
false = objekt ist futsch.
so kann dein IF-block um ein weiteres IF-"boolean" ergänzt werden ;-)))

[Daniel]

Moin,

Dein Engagement als neues Mitglied des Forums in alle Ehren. Aber Dein Ratschlag hier ist haarsträubend. Wenn das boolsches Flag Teil des Objektes ist, dann geht es mitsamt dem Objekt unter, wenn das Objekt freigegeben wird. Und eine frei herumbaumelnde boolsche Variable als "Buchhaltung", ob ein Objekt noch da ist oder nicht, führt in kürzester Zeit zum Chaos.

[MichaelT]

Die Diskussion ist so alt wie der Pointer selbst. Entweder man programmiert passiv und frägt in der Funktion alles ab oder man ist aktiv und prüft Zeiger vor der Übergabe.

Aktiv kann man so weit treiben, dass man Fehler in der Logik auf Speicherverletzungen zurückführt oder einfach bieder prüft bevor man ein Objekt zumeist an eine Prozedur/Methoden usw.. übergibt.

Wenn man weiß was man tut, kann man auch mit einem NULL Objekt arbeiten, sprich ein leeres Objekt mit gültiger Speicheradresse. Das wäre was in der Antwort nach deiner wurde angedeutet.

Als Beispiel aus der reinen prozeduralen Welt einen Ringbuffer als doppelt verkettete Liste realsiert in die man nur in der Mitte einfügt und rauslöscht wäre ähnlich gelagert.

Damit man aber nicht verrückt müsst man ein reines Objektsystem (ala) Smalltalk haben oder Mehrfachvererbung. Eine Interface welches Assigned zurückgibt usw...

Sämtliche passive Varianten leiden of darunter schwer zu debuggen zu sein. Du bekommst teils 'Side Effect' artige technisch korrekte, aber anwendungssemantisch schlicht falsche Ergebnisse. Logikfehler werden einfach verschleppt.

Zitat:

Zitat von Zacherl (Beitrag 1386206)

Zitat:

Zitat von TigerLilly (Beitrag 1386195)

Deshalb bleibe ich dabei:
Wenn ich mir während ich auf einem Objekt arbeite (sogar zwischen zwei Bedingungen/Funktionsaufrufen in einer Abfrage) dieses Objekt selbst unter den Füßen wegziehe, indem ich es zerstöre, dann ist das nunmal - vorsichtig ausgedrückt - kein optimales Code-Design. Sowas passiert auch (die Verwendung von Threads mal abgesehen) wirklich nur dann, wenn man nicht eindeutig definiert, wer ein Objekt "besitzt". Im Optimalfall sollte der Besitzer das Objekt sowohl erstellen, als auch nach getaner Arbeit wieder freigeben.

[Fukiszo]

was ich meinte war:

var
objectAvail: boolean;

begin
objectAvail := False;
procedure initObject;
begin
...code der das object zur verfügung stellt und festgestellt wird obs initialisiert ist mit diesem ergebnis:
objectAvail:= True;
end;
procedure killObject;
begin
...code der das object freigibt mit diesem ergebnis:
objectAvail:= False;
end;

initObject;
IF-block start..
if objectAvail then ...code
endif;
end;

oder hab ich alles falsch verstanden?

[himitsu]

Und jetzt das nochmal mit zwei Instanzen dieser Klasse, aber weiterhin nur mit der einen globalen Variable. :angle:

[MichaelT]

Der Sinn von einem Record und auch das revolutionäre der Verbundstrukturen war, dass man Informationen Gruppieren konnte und pro Instanz konnte gemeinsam verwalten. Ein Objekte als Instanz einer Klasse fällt in diese Kategorie. Vorher gab es nur ARRAYS von Basisdatentypen.

Aber du kannst nur auf Informationen bestehender Verbundstrukturen zugreifen und sonst sind die Objekte gleich und das wird ausgedrückt durch NULL/NIL.

Du sagst, 'Not In List'. Alternativ dazu wäre das NULL resp. Leere Objekt. In dem könnte man isAlive := False setzen.

Selbst wenn du eine Verbundstruktur schachtelst.

Delphi-Quellcode:

type TEnvelope = record
  // pointer to object
  reference : POINTER TO AbstractDataType // in Modula Slang
  isAlive : boolean;
end;

Kannst du dir noch immer nicht sicher sein, ob die Referenz noch lebt. Du könntest das zwar mit Klassen machen und sicherstellen, dass IsAlive private bleibt und nur ausglesen werden kann und unter Verantwortung der Klasse TEnvolope synchron mit der Erzeugung einer Objektinstanz gesetzt wird usw... Das Problem ob der Envelope initialisiert ist bleibt und damit ist nichts gewonnen.

Dann hast du nur Schnittstellen die TEnvelopes übergeben bekommen :-D

Du kannst noch die Erzeugung der Objekte der Klasse überlassen und die Verwaltung ihrer Instanzen und indirekt zugreifen. Im Fall von NotAssigned käme ein leeres Objekt zurück. Damit würdest du die Abfrage mit Assigned netter gestalten, aber ändert nichts am langen Ende. Dadurch, dass die Klasse die Objekte selbst verwaltet verschwindet auch deine Verantwortung dieses Singelton freizugeben.

Zitat:

Zitat von Fukiszo (Beitrag 1391009)

was ich meinte war:

var
objectAvail: boolean;

begin
objectAvail := False;
procedure initObject;
begin
...code der das object zur verfügung stellt und festgestellt wird obs initialisiert ist mit diesem ergebnis:
objectAvail:= True;
end;
procedure killObject;
begin
...code der das object freigibt mit diesem ergebnis:
objectAvail:= False;
end;

initObject;
IF-block start..
if objectAvail then ...code
endif;
end;

oder hab ich alles falsch verstanden?