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

[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 von Zacherl:

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 von TigerLilly:

Zitat von Zacherl:

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 von Zacherl:

Zitat von TigerLilly:

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.

[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

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 von 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?