Assigned=true bei uninitialisierter Variable ?

[Int3g3r]

Guten Abend,

Delphi-Quellcode:

procedure THeaderFooterForm.FormActivate(Sender: TObject);
var server : TServer;
begin
   //server := nil;
   if not assigned(server) then
      server := TServer.Create('127.0.0.1',25222,true);
      server.StopTCPServer;
      FreeAndNil(server);
end;

Ich verwende hier eine lokale Variable für den TServer.
Wenn ich am Anfang "server := nil;" nicht schreibe ist assigned true und das Create Event wird übersprungen.
Somit erhalte ich eine exception sobald ich auf die Variable zugreife.

Kann mir jemand erklären warum assigned = true ist bei einer lokalen Variable die wie hier zu sehen sonst gar nicht verwendet wird ?

Ich kann mir nur vorstellen das per Zufall an dieser Adresse gerade ein Objekt "ist/vorher war" und daher assigned true zurück gibt, ist dies korrekt ?
Lokale Variablen werden ja nie initialisiert somit haben diese einen undefinierten Wert.
Somit wäre es zwingend notwenig in diesem Fall die Variable zu initialisieren.

Gruss Int3g3r

[DeddyH]

Assigned heißt ja nichts anderes, als dass die Variable nicht nil ist. Wie Du bereits weißt, sind lokale Variablen nicht initialisiert, da ist die Wahrscheinlichkeit verschwindend gering, dass sie bei ihrer Deklaration eine 0-Entsprechung (also nil) enthält, Assigned gibt also true zurück.

[Hobbycoder]

Du erzeugst ja lokal nur eine Variable vom Typ TServer. Im Speicher existiert das Object noch gar nicht.
Demnach kannst du dir die Prüfung mit not Assigned an der Stelle schenken. Assigned wird dann immer False bzw. not Assigned immer True liefern. Tut es zumindest bei mir.
Die Assinged-Prüfung macht erst NACH dem Create Sinn. Denn erst dann wird der Speicher reserviert und die Adresse zugewiesen, sofern dabei kein Fehler auftritt.

Zweitens müsste du nach deinem if Assigned() then auch in einem Block weitermachen.

Delphi-Quellcode:

procedure THeaderFooterForm.FormActivate(Sender: TObject);
var server : TServer;
begin
  server := TServer.Create('127.0.0.1',25222,true);
  if assigned(server) then
  begin
    server.StopTCPServer;
    FreeAndNil(server);
  end;
end;

Noch besser wäre so:

Delphi-Quellcode:

procedure THeaderFooterForm.FormActivate(Sender: TObject);
var server : TServer;
begin
  try
    server := TServer.Create('127.0.0.1',25222,true);
    try
      server.StopTCPServer;
    finally
      FreeAndNil(server);
    end;
  except
    ShowMessage('Server konnte nicht gestartet werden.');
  end;
end;

Assigned solltest du verwenden, wenn bestimmte Codeabschnitte nur ausführbar sind, wenn eine Variable<>nil ist. Um Fehler abzufangen: Try..Except

[himitsu]

Tja, lokale Variablen sind nunmal per se niemals initialisiert (mit einigen Ausnahmen) und sind potentiell mit Zufallswerten gefüllt,
also musst du vorher irgendwas zuweisen, bevor du den Inhalt prüfen oder auslesen willst.

Zufallswerte: einmal 0 oder uber 4 Milliarden Mal was Anderes und die Stochastik lehrt dich, dass du wahrscheinlich meistens keine 0 bekommst. :angle:

Zitat:

Delphi-Quellcode:

var server : TServer;
begin
   //server := nil;
   if not assigned(server) then

Ich hoffe mal der Compiler hat dich korrekt ausgemeckert, dass du auf eine uninitialisierte Variable zugreifst.

Fazit: Du darfst die Zuweisung nicht auskommentieren,
oder lass sie nutzlose vorherige Zuweisung und das IF-Assigned einfach weg (siehe Vorredner) und initialisiere die Variable mit deiner neuen Instanz.



keine Ressourcenschutzblöcke?
Wenn es im StopTCPServer knallt, dann hast du ein wunderschönes Speicherleck.

[Heimlich]

Zitat:

Zitat von Hobbycoder (Beitrag 1468223)

Noch besser wäre so:

Delphi-Quellcode:

procedure THeaderFooterForm.FormActivate(Sender: TObject);
var server : TServer;
begin
  try
    server := TServer.Create('127.0.0.1',25222,true);
    try
      server.StopTCPServer;
    finally
      FreeAndNil(server);
    end;
  except
    ShowMessage('Server konnte nicht gestartet werden.');
  end;
end;

Was ist, wenn der Fehler in StopTCPServer passiert, dort aber keine Fehlerbehandlung erfolgt?

[himitsu]

Zitat:

Zitat von Hobbycoder

Noch besser wäre so

Nicht wirklich.

Man vernichtet nicht sinnlos Fehlermeldungen.
Weiterer Text als Zusatzinfo ist OK, aber wenn dann mit der Originalmeldung im Fenster (unten zum Aufklappen oder auf Knopfdruck), oder zumindestens in einem Log.

[Heimlich]

Zitat:

Zitat von himitsu (Beitrag 1468245)

Zitat:

Zitat von Heimlich (Beitrag 1468244)

Noch besser wäre so

Nicht wirklich.

Man vernichtet nicht sinnlos Fehlermeldungen.
Weiterer Text als Zusatzinfo ist OK, aber wenn dann mit der Originalmeldung im Fenster (unten zum Aufklappen oder auf Knopfdruck), oder zumindestens in einem Log.

Ist mir eigentlich ziemlich wurscht, da Du den Falschen zitiert hast. Das try..except wird einfach falsch verwendet und die Meldung ist auch Fail. Kann richtig sein, muss aber nicht. Die Meldung kann zu Zeitverschwendung bei der Fehlersuche führen.

[himitsu]

Ups, den falschen gesteinigt.
Dann nehm ich den Felsen erstmal heimlich wieder runter, hat ja niemand gesehn. :stupid:

Zitat:

Zitat von Heimlich

Die Meldung kann zu Zeitverschwendung bei der Fehlersuche führen.

Und jupp, genau deswegen.

[Hobbycoder]

Zitat:

Zitat von Heimlich (Beitrag 1468247)

Ist mir eigentlich ziemlich wurscht, da Du den Falschen zitiert hast. Das try..except wird einfach falsch verwendet und die Meldung ist auch Fail. Kann richtig sein, muss aber nicht. Die Meldung kann zu Zeitverschwendung bei der Fehlersuche führen.

Die Meldung mit ShowMessage diente mehr der Veranschaulichung. Was ist denn bitte an dem try..except falsch, außer er Tatsache dass man statt der Meldung eine Fehlercode ausgeben könnte? Wie und Welche Fehlermeldung der TE ausgeben will weiß ich doch nicht und könnte er auch selber machen.

[Int3g3r]

Vielen Dank für alle Kommentare und Klarstellungen.