Bubblen Exceptions nach oben durch einen try-finally-Block?

[DGL-luke]

Hallo, folgende Struktur:

Delphi-Quellcode:

try
  with TSomeClass.Create do
    try
      SomeMethod;
      SomeMethodThatThrows; //wirft Exception!
    finally
      Free;
    end;
except
  on E:Exception do
    ShowmEssage(E.Message);
end;

Ich will eine Fehler bei der Erstellung der Klasse abfangen - innerhalb des try...finally-blocks interessieren mich keine Exceptions.

Klappt das oder kommt die Exception, die ich oben markiert hab, aus dem try...finally-block irgendwie raus?

[3_of_8]

Delphi-Quellcode:

with TSomeClass.Create do
try
  SomeMethod;
  SomeMethodThatThrows; //wirft Exception!
except
  on E:Exception do
    ShowmEssage(E.Message);
end;
Free;

So würd ich das machen.

[mkinzler]

Es dürfte kein Exception außerhalb des Blocks entstehen.

[DGL-luke]

Negatori.

Ich will es abfangen, wenn die Klasse beim Erzeugen wirft. Im Konkreten geht es um einen Filestream.

@mkinzler: Ja, glaube das reicht mir.

[3_of_8]

Das hättest du auch dazusagen können.

[DGL-luke]

Hab ich.

Zitat:

Zitat von DGL-luke

Ich will eine Fehler bei der Erstellung der Klasse abfangen

Und es ist mir egal, ob du sagst "du hast ja editiert". Ich hab da nur einen Buchstaben im titel geändert. (Kann das einer der Mods vielleicht bestätigen? ka, ob ihr da n versioning habt... :gruebel: )

[PaulJr]

Hallo DGL-luke,

man könnte dies z.B. so machen:

Delphi-Quellcode:

var
  SomeClas : TSomeClas;
Begin

try
  SomeClas := TSomeClas.Create;
 If SomeClas <> NIL then 
 with SomeClas do 
    try 
      SomeMethod; 
      SomeMethodThatThrows; //wirft Exception! 
    finally 
      Free; 
    end; 
except 
  on E:Exception do 
    ShowmEssage(E.Message); 
end;

end;

Gruß :???:

PaulJr.

[jbg]

Zitat:

Zitat von PaulJr

SomeClas := TSomeClas.Create;
If SomeClas <> NIL then

Und in welchem Fall würde TSomeClas NIL zurückliefern? - In keinem. Somit ist die if-Anweisung sinnlos.

[3_of_8]

Ich vermute mal, wenn der Konstruktor eine Exception wirft, bleibt der Pointer so, wie er vorher war. Das heißt, wenn man ihn vorher mit nil initialisiert, würde es gehen.

[Luckie]

Das funktioniert:

Delphi-Quellcode:

procedure TForm1.Button1Click(Sender: TObject);
var
  fs: TFileStream;
begin
  try
  fs := TFileStream.Create('c:\test.txt', fmCreate);
  try

  finally
    FreeAndNil(fs);
  end;
  except
   on E: Exception do
     ShowMessage('foobar');
   end;
end;

Ich habe keine Schreibrechte auf c:\ und als Nachricht wird foobar aisgegeben.

[Elvis]

Das finally wird keine Exception schlucken, aber es wird trotzdem ausgeführt.
Aber die große Frage ist, warum du die Exception an der Stelle auf eine so fiese Art schlucken willst?
Solche Art von Code sollte IMHO nur dann Exceptions schlucken, wenn sie recoverable sind, also wenn die App nach Ablauf der Funktion immer noch in einem konsistenten Zustand ist.
Ein Beispiel wäre eine disconnected gracefully mit einem folgendem Reconnect.
Wenn du eine Datei erzeugen willst, dies aber nicht möglich ist, kann sich deine Methode schlecht von dieser Ausnahme erholen. Sie hat also IMHO kein Recht die Ausnahme zu schlucken.
Nur der Code, der die Funktion ausführt, kann das beurteilen.
Und dann vielleicht auch den Benutzer benachrichtigen.

[PaulJr]

Tja… da hast Du wirklich Recht.

Ich habe nur probiert Dein Konstrukt zu Recht zu biegen.

Es geht dies z.B. auch so wie Dir Luckie jetzt gerade gezeigt hat (Hallo Lucke :-D )

In meinem Konstrukt wollte ich Dich nur auf die wichtigste Tatsache aufmerksam machen, dass man NIE die Routine FREE aufruft ohne vorher den Pointer zu überprüfen, da falls NIL dann hast Du ein echtes Problem.

Gruß

PaulJr.

[Luckie]

Zitat:

Zitat von PaulJr

dass man NIE die Routine FREE aufruft ohne vorher den Pointer zu überprüfen, da falls NIL dann hast Du ein echtes Problem.

Nein hat er nicht, da Free vorher auf nil prüft und nur dann den Destruktor aufruft, wenn da Objekt nicht nil ist:

Zitat:

Free automatically calls the destructor if the object reference is not nil. [..] Unlike Destroy, Free is successful even if the object is nil; so if the object was never initialized, Free won’t result in an error.

Zitat:

Zitat von PaulJr

(Hallo Lucke :-D )

Ähm, ich stehe gerade etwas auf dem Schlauch... Allerdings kommt mir der Nick PaulJr irgendwie bekannt vor. :gruebel:

[PaulJr]

Habe natürlich Luckie :???: gemeint. Ja ich bin der "alte" PaulJr.

Gruß

PaulJr.

P.S.

Ich meinte Luckie nicht Deine Routine (die ist OK!)sondern das was er programmiert hatte...

[Elvis]

Zitat:

Zitat von PaulJr

Tja… da hast Du wirklich Recht.

Na das kann ich für Dich nur hoffen. :mrgreen:

Zitat:

In meinem Konstrukt wollte ich Dich nur auf die wichtigste Tatsache aufmerksam machen, dass man NIE die Routine FREE aufruft ohne vorher den Pointer zu überprüfen, da falls NIL dann hast Du ein echtes Problem

Stümmt nicht. Das Free kann nur aufgerufen werden, wenn der Konstruktor erfolgreich war.
Es kann also nach der der Erzeugung der Instanz unmöglich mit einer nil-Referenz gearbeitet werden.
Exceptions gehören genauso zur Flusskontrolle wie Schleifen oder if-Statements. ;)

Der Code von Luke wäre IMO in einer simpelsten Form auch am richtigsten:

Delphi-Quellcode:

var
  putNameHere : TSomeClas;
begin
  putNameHere := TSomeClas.Create();
  try
    putNameHere.SomeMethod();
    putNameHere.SomeMethodThatThrows(); //wirft Exception!
  finally
    putNameHere.Free();
  end;
end;

btw: Bist du der PaulJr?
Ahh der rote Katen fehlte, du bist es also. Habe schon einiges von dir gehört. War allerdings bevor ein gewisser Robert_G dieses Forum heimsuchte. :mrgreen:

[3_of_8]

Zitat:

Es kann also nach der der Erzeugung der Instanz unmöglich mit einer nil-Referenz gearbeitet werden.

Free ist eine statische Methode, man kann sie sehr wohl aufrufen, auch wenn die Klasse nicht instantiiert ist. Free ist sogar so freundlich, sich selbst abzubrechen, wenn Self=nil. Nur wenn der Instanzenpointer nicht nil ist, krachts.

EDIT:

Delphi-Quellcode:

procedure TForm1.FormCreate(Sender: TObject);
var a: TObject;
begin
  a:=nil;
  a.Free; //Das kracht nicht
  a.ClassType; //Das schon
end;

[Elvis]

Zitat:

Zitat von 3_of_8

Zitat:

Es kann also nach der der Erzeugung der Instanz unmöglich mit einer nil-Referenz gearbeitet werden.

Free ist eine statische Methode, man kann sie sehr wohl aufrufen, auch wenn die Klasse nicht instantiiert ist. Free ist sogar so freundlich, sich selbst abzubrechen, wenn Self=nil. Nur wenn der Instanzenpointer nicht nil ist, krachts.

Da sagst du mir nix neues. ;) Ändert auch nix an meinem Punkt, oder? :zwinker:

[PaulJr]

Ja Elvis :) , der bin ich…(bin für ein paar Jahre ausgestiegen… und jetzt bin ich zurück… und offensichtlich sollte ich etwas genauere Antworten geben: Versprochen :idea: )

Ja in diesem Fall hast natürlich Recht.

Ich bin alte Programmierer und programmiere immer so… ist aber nicht so weiter wichtig…

Gruß

PaulJr.

[PaulJr]

Var
StringList : TstringList;
Begin
StringList.Free; // da kommt leider Exeption…

Das allerdings geht in die Hosen :shock:

[Luckie]

Zitat:

Zitat von PaulJr

Habe natürlich Luckie :???: gemeint. Ja ich bin der "alte" PaulJr.

Herzlich willkommen zurück. :P :hi: Schreib mal eine PN, was du so gemacht hast und wie es dir ergangen ist. Hier hat sich ja viel getan, wie du siehst. ;)

[3_of_8]

Klar. Weil der Pointer da nicht initialisiert ist. Wenn du ihn auf nil setzt, geht es.

@Elvis: Hab dich falsch verstanden. ;)

[Elvis]

Zitat:

Zitat von PaulJr

Var
StringList : TstringList;
Begin
StringList.Free; // da kommt leider Exeption…

Das fiese an einer nicht typensicheren ist, dass es nicht knallen muss.
StringList könnte genauso gut irgendwo hin zeigen, wo vorher eine richtige Instanz lag.

Zitat:

Das allerdings geht in die Hosen :shock:

Jupp, aber auch nur weil es doch arg mit den kleinkarierten Samthandschühchen an den Haaren herbeigezogen wurde. :zwinker:

[PaulJr]

Hallo 3_of_8 :-D

Schon klar, das ist das gerade. Es ist nicht oft so, dass ein Objeckt in einer Routine erzeugt wird und dann SOFORT freigegeben.

Viel mehr gibt man oft so erzeugte Objecte in anderen Routinen frei (z.B. in OnClose)

Darum es ist notwendig der Status NIL abzufragen…

Hier stimme ich Dir zu…

Gruß

PaulJr.

P.S.

Hallo Luckie, :-D

eines Tages schreibe ich Dir… aber jetzt bin ich schwer an programmieren.
Ja, Du hast Recht…, es ist hier irgendwie sehr angenehm geworden (oder ich bin netter geworden… oder vielleicht beides )

Viele Grüße

PaulJr.