Fehlerbehandlung

[Eclipticon]

Guten Morgen!

Gehe ich recht in der Annahme, dass diese zwei Teile Codes prinzipiell das gleiche machen, d.h. ich mir in der zweiten Variante dden finally-Block sparen kann, ASomething aber trotzdem auf jeden Fall freigebe?

Code: Alles auswählen

procedure Test;
var
   ASomething: TSomething;
begin
  try
    try
      ASomething := TSomething.Create;
      ASomething.DoSomething;
      //....
    finally
      ASomething.Free;
    end;
  except
    on E: Exception do ShowMessage(...);
  end;
end;

Code: Alles auswählen

procedure Test;
var
   ASomething: TSomething;
begin
  try
    ASomething := TSomething.Create;
    ASomething.DoSomething;
    //....
  except
    on E: Exception do ShowMessage(...);
  end;
  ASomething.Free;
end;

Danke!

[m.fuchs]

Gehe ich recht in der Annahme, dass diese zwei Teile Codes prinzipiell das gleiche machen, d.h. ich mir in der zweiten Variante dden finally-Block sparen kann, ASomething aber trotzdem auf jeden Fall freigebe?

Nein, wenn innerhalb deiner except-Behandlung wieder eine Exception geworfen wird, dann wird ASomethingFree; nicht erreicht:

Code: Alles auswählen

procedure Test;
var
   ASomething: TSomething;
begin
  try
    ASomething := TSomething.Create;
    ASomething.DoSomething;
  except
    on E: Exception do raise Exception.Create('maeh');
  end;
  ASomething.Free;
end;

Daher ist die sicherste Variante immer:

Code: Alles auswählen

try
  try
  except
  end;
finally
end;

hth
Michael

[Socke]

Code: Alles auswählen

procedure Test;
var
   ASomething: TSomething;
begin
  try
    try
      ASomething := TSomething.Create;
// […]

Du solltest, bevor du dein Objekt erstellst, die Objekt-Variable auf nil setzen. Wird nämlich innerhalb des Konstruktors eine Exception ausgelöst, löst .Free mit Sicherheit noch eine aus…

[Heinrich Wolf]

Ich dachte, wenn innerhalb des Konstruktors eine Exception ausgelöst wird, dann wird das Result des Konstruktors zurückgegeben. Damit wäre das NIL wieder weg und das Result wäre ein halb initialisiertes Objekt, das mit Free freigegeben werden muss. Dasselbe gilt natürlich für alles, was innerhalb des Konstruktors passiert. Darin kann ja ein weiterer Konstruktor und try stehen. Wenn das nicht so ist, befürchte ich ein Speicherleck, sobald eine Exception im Konstruktor auftritt. Bei news.embarcadero.com lese ich zwar immer folgendes:

Code: Alles auswählen

Object := tObject.Create;
try
  // Arbeite mit Object
finally
  Object.free;
end;

aber ich mache es oft so:

Code: Alles auswählen

Object := Nil;
try
  Object := tObject.Create;
  // Arbeite mit Object
except
  on e : Exception do
    Application.MessageBox(e.Message, Caption, mb_IconHand);
end;
Object.free;

Schade, dass man except nicht mit finally kombinieren kann. Aber Free auf Nil ist ja erlaubt. Ich nehme gern except, weil ich e.Message sehen möchte.

[Socke]

Ich dachte, wenn innerhalb des Konstruktors eine Exception ausgelöst wird, dann wird das Result des Konstruktors zurückgegeben. Damit wäre das NIL wieder weg und das Result wäre ein halb initialisiertes Objekt, das mit Free freigegeben werden muss.

Wird innerhalb eines Konstruktors eine Exception ausgelöst (gilt auch für dort aufgerufene Funktionen), die nicht gefangen wird, wird direkt der Destruktor aufgerufen. Daher muss dieser auch nicht vollständig erstellte Objekte wieder vollständig freigeben können.
Hinterher hat die Objektvariable den gleichen Wert wie vorher.

[Heinrich Wolf]

Hmm. Wenn der Destruktor automatisch aufgerufen wird, dann führt mein Code zu einer Schutzverletzung, weil das Objekt nicht mehr nil ist, aber schon freigegeben wurde. Wie kommt man da sauber raus? z.B. so?

Wenn man die Exception Message haben will:

Code: Alles auswählen

try
  Object := tObject.Create;
  try
    // Arbeite mit Object
  except
    on e : Exception do
      Application.MessageBox(e.Message, Caption, mb_IconHand);
  end;
  Object.free;  
except
  on e : Exception do
    Application.MessageBox(e.Message, Caption, mb_IconHand);
end;

Wenn man die Exception Message nicht braucht, so wie ich oben news.embarcadero.com zitiert habe.

[Heinrich Wolf]

... Bei news.embarcadero.com lese ich zwar immer folgendes:

Code: Alles auswählen

Object := tObject.Create;
try
  // Arbeite mit Object
finally
  Object.free;
end;

...

Dabei wird die Exception, die vom Create kommen kann, nicht abgefangen. Also braucht man auch hier ein zweites try

Code: Alles auswählen

try
  Object := tObject.Create;
  try
    // Arbeite mit Object
  finally
    Object.free;
  end;
except
  on e : Exception do
    Application.MessageBox(e.Message, Caption, mb_IconHand);
end;

[Socke]

Hmm. Wenn der Destruktor automatisch aufgerufen wird, dann führt mein Code zu einer Schutzverletzung, weil das Objekt nicht mehr nil ist, aber schon freigegeben wurde. Wie kommt man da sauber raus?

Indem man die Objektvariable vor Aufruf des Konstruktors auf nil setzt.

Die häufigste Ursache für Exceptions innerhalb des Konstruktors ist wohl die unsachgemäße Verwendung einer Klasse, was in einem Produktiv-System nicht auftreten sollte. Wenn kein Speicher mehr reserviert werden kann, tritt die Exception streng genommen schon vor dem Konstruktor auf, aber in dem Fall hat in der Regel dein gesamtes Computer-System Probleme.

[Heinrich Wolf]

Hmm. Wenn der Destruktor automatisch aufgerufen wird, dann führt mein Code zu einer Schutzverletzung, weil das Objekt nicht mehr nil ist, aber schon freigegeben wurde.

Hinterher hat die Objektvariable den gleichen Wert wie vorher.

Es ist also immer noch nil, weil es durch die Exception nicht zur Zuweisung gekommen ist. Dann gibt es auch keine Schutzverletzung.

[Socke]

Es ist also immer noch nil, weil es durch die Exception nicht zur Zuweisung gekommen ist. Dann gibt es auch keine Schutzverletzung.

In deinem Code wird die Objektvariable nicht initialisiert und kann daher jeden Wert haben; dass sie ausgerechnet nil ist, hat eine Wahrscheinlichkeit von 1:4294967296.

[Heinrich Wolf]

14:27 Du hast recht!

17:30 ergänzt:
Ich hab meine Code Schnipsel noch mal durchgeschaut. In keinem der Fälle, wo der Konstruktor eine Exception wirft, wird free erreicht. Allerdings ist das Objekt dann nicht notwendiger Weise Nil. Nil wäre natürlich besser für den Code außen herum. Und Object := Nil; nach Object.Free; wäre auch nicht schlecht, auch wenn Rudy Velthuis vom TeamB dagegen wettert.

https://forums.embarcadero.com/thread.j ... adID=57845

[Socke]

Nil wäre natürlich besser für den Code außen herum. Und Object := Nil; nach Object.Free; wäre auch nicht schlecht, auch wenn Rudy Velthuis vom TeamB dagegen wettert.

Irgendwann mutiert das zu einer akademischen Frage, deren Antwort für das Software-Design vollkommen irrelevant ist.

Ich hab meine Code Schnipsel noch mal durchgeschaut. In keinem der Fälle, wo der Konstruktor eine Exception wirft, wird free erreicht.

Ja, das kommt dann immer auf die konkrete Situation an, wo genau welche Zeile im Code steht.

[Eclipticon]

Hi,

danke fuer Euer Feedback ... wenn ich nicht gerade Beispielcode schreibe, initialisiere ich meine Objekte auch alle mit nil:

Code: Alles auswählen

var
  ASomething: TSomething = nil;

Hierzu aber noch eine Frage: Objektinstanzen, die Teile eines anderen Objekts sind kann ich nur "zu Fuss" z.B. im constructor mit nil initialisieren, oder?

Danke!

[Socke]

Hierzu aber noch eine Frage: Objektinstanzen, die Teile eines anderen Objekts sind kann ich nur "zu Fuss" z.B. im constructor mit nil initialisieren, oder?

Der gesamte Speicher eines Objektes wird beim Anlegen der Instanz — also noch vor Aufruf des Konstruktors — mit Nullen überschrieben. Die Felder (Variablen eines Objekts) nochmals mit nil oder Null zu überschreiben hat also wenig Sinn, außer, dass es noch einmal explizit im Benutzer-Code geschieht und man es lesen kann.

[theo]

Irgendwann mutiert das zu einer akademischen Frage, deren Antwort für das Software-Design vollkommen irrelevant ist.

Schön gesagt.
Ich habe ausserdem oft das Gefühl, dass man das Exception-Handling nicht unbedingt zu Ende denken sollte,
das gibt nur Kopfschmerzen und ist dann meistens in der Praxis umso unbrauchbarer, je mehr man sich überlegt hat.