Falsche Verwendung von try...except...end

[smudo]

Zitat:

Zitat von Terminator

Frag mich nun folgendes:
1. In obigen Beispiel wird doch s1 auch IMMER freigegeben oder hab ich da nen Denkfehler?.
2. Was passiert eigentlich wenn s1 nicht freigegeben wird? Wird nur unnötig Speicher belegt bis das Programm endet?

1.) Nein, wird nicht immer freigegeben. Nach einer Exception wird nur noch der Except-Block ausgeführt. Du musst also auch in den Except-Block das freigeben integrieren.

2.) Ja. Es wird unnötiger Speicher belegt. Und das u.U. über das Programmende hinaus

René

[RavenIV]

Zitat:

Zitat von Terminator

Delphi-Quellcode:

TRY
    ...
    sl:=TStringList.create;  // Resource belegen 
    ...
EXCEPT
    on E:Exception do
    begin
        Loggen
    end;
END;
s1.Free

Frag mich nun folgendes:
1. In obigen Beispiel wird doch s1 auch IMMER freigegeben oder hab ich da nen Denkfehler?.
2. Was passiert eigentlich wenn s1 nicht freigegeben wird? Wird nur unnötig Speicher belegt bis das Programm endet?


cu
Terminator

zu 1.
nein sl wird nicht freigegeben, weil der Ablauf in den except-Teil springt und anschliessend die procedure verlassen wird.
zu 2.
du bekommst Speicherlöcher (memory leaks), weil der Speicher belegt bleibt und nicht neu zugewiesen werden kann. Ausserdem kannst Du unerwartete Nebeneffekte bekommen, wenn Du z.B. sl neu erzeugst. Also immer schauen, dass alle mit create angelegte Objekte auch wieder ein free erfahren.

[smudo]

:bounce2: Erster !

[RavenIV]

Zitat:

Zitat von smudo

:bounce2: Erster !

es kam kein roter Kasten :?

[himitsu]

@Terminator
du kannst try-finally/except auch verschachteln :zwinker:

entweder erst die excption behandeln und dann freigeben

Code:

try
{
    ...
}
except
{
    ...
}
finally
{
    ...
}

=

Delphi-Quellcode:

try
  try
    ...
  except
    ...
  end;
finally
  ...
end;

oder erst freigeben und dann die Exception

Code:

try
{
    ...
}
finally
{
    ...
}
except
{
    ...
}

=

Delphi-Quellcode:

try
  try
    ...
  finally
    ...
  end;
except
  ...
end;

Aber stimmt schon ... zusammen (als ein Try-Block) hab ich's mir auch schon gewünscht :roll:

[MStoll]

Zitat:

Zitat von smudo

1.) Nein, wird nicht immer freigegeben. Nach einer Exception wird nur noch der Except-Block ausgeführt. Du musst also auch in den Except-Block das freigeben integrieren.

Hi,

wenn nur noch der Except-Block ausgeführt werden würde, das wäre ja schrecklich. Das ist nicht so! Es kann ja nicht sein, dass man bei ner Exception keine Möglichkeit mehr hat, hinter dem Teil mit der Exception weiterzumachen.

Gruß
Michael

[Sidorion]

Dass das noch niemandem aufgefallen ist:

Zitat:

Delphi-Quellcode:

// in folgendem Beispiel werden Daten aus einer Query gelesen
// Fehler werdem in einem Memo protokolliert und der Lesevorgang geht weiter
// es werden keine Informationen unterdrückt, sondern die Fehlermeldungen werden protokolliert
while not Query1.Eof do
begin
  try
    MachWas(Query1);
  except
    on E:Exception do
    begin
       MemoLog.Lines.Add('Fehler in MachWas');
       MemoLog.Lines.Add(E.ClassName+':'+E.Message);
       MemoLog.Lines.Add('Record: ' +IntToStr(Query1.RecNo);
    end;
   Query1.Next;  // nächster Datensatz
  end;
end;

Hier wird Query1.Next nur gerufem, falls es zu einer Exception gekommen ist. Sobald ein Datensatz durchläuft, wirds ne Endlosschleife. besser:

Delphi-Quellcode:

// in folgendem Beispiel werden Daten aus einer Query gelesen
// Fehler werdem in einem Memo protokolliert und der Lesevorgang geht weiter
// es werden keine Informationen unterdrückt, sondern die Fehlermeldungen werden protokolliert
while not Query1.Eof do
begin
  try
    try
      MachWas(Query1);
    except
      on E:Exception do
      begin
         MemoLog.Lines.Add('Fehler in MachWas');
         MemoLog.Lines.Add(E.ClassName+':'+E.Message);
         MemoLog.Lines.Add('Record: ' +IntToStr(Query1.RecNo);
      end;
    end;
  finally
    Query1.Next;  // nächster Datensatz
  end;
end;

[shmia]

@Sidorion: da hast du natürlich Recht, aber dein Lösungsvorschlag war nicht so gut.

Delphi-Quellcode:

// in folgendem Beispiel werden Daten aus einer Query gelesen 
// Fehler werdem in einem Memo protokolliert und der Lesevorgang geht weiter 
// es werden keine Informationen unterdrückt, sondern die Fehlermeldungen werden protokolliert 
while not Query1.Eof do 
begin 
  try 
    MachWas(Query1); 
  except 
    on E:Exception do 
    begin 
       MemoLog.Lines.Add('Fehler in MachWas'); 
       MemoLog.Lines.Add(E.ClassName+':'+E.Message); 
       MemoLog.Lines.Add('Record: ' +IntToStr(Query1.RecNo); 
    end; 
  end; 
  Query1.Next;  // nächster Datensatz 
end;

Das Query1.Next ist nun an der richtigen Stelle; try..finally wird hier nicht benötigt.

[Sidorion]

Schon, aber Du weißt ja, wie das ist: In fünf Monaten macht da irgendwer ein raise; dran und dann wars wieder keiner ;)

[altlastenverwalter]

Die 5. Sünde ist Unfug (zumindest bei Delphi 6 - hab gerade keine andere Version parat).

Einen finally-Handler benötigt man nur, wenn man Exceptions nicht gesondert behandeln möchte.
Selbstverständlich wird nach dem Except normal weitergemacht und eben nicht die Prozedur verlassen!

Delphi-Quellcode:

procedure TForm1.Button1Click(Sender: TObject);
var a,b: double;
begin
 try
 b := 0;
 a := 666;
 a := 10 / b;
 except
   ShowMessage('nulldivision');
 end;
 ShowMessage(FloatToStr(a));
end;

Beide ShowMessage werden ausgeführt.

Ich weiß, dass dieser Thread alt ist, aber leider ist das der 3. Google-Treffer, wenn man nach Delphi-Exception sucht. Habe mich extra angemeldet in der Hoffnung, dass der Threadersteller seinen Eingangsbeitrag noch editieren könnte, damit nicht weiterhin diese Unwahrheit verbreitet wird.