Delphi-PRAXiS
Seite 3 von 4     123 4      

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Tutorials und Kurse (https://www.delphipraxis.net/36-tutorials-und-kurse/)
-   -   Delphi Falsche Verwendung von try...except...end (https://www.delphipraxis.net/26234-falsche-verwendung-von-try-except-end.html)

Bernhard Geyer 23. Aug 2010 08:39

AW: Falsche Verwendung von try...except...end
 
Zitat:

Zitat von altlastenverwalter (Beitrag 1044282)
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!

Ist kein Unfug. Finally ist zur Freigabe von Ressourcen zu verwenden! Es wurde auch nicht davon gesprochen das im except-Teil die Funktion verlassen wird. Wird z.B. statt einer Exption ein exit aufgerufe wird dein Code nach dem Except nicht aufgerufen, der Finally-Teil trotzdem.

himitsu 23. Aug 2010 08:53

AW: Falsche Verwendung von try...except...end
 
Und wenn in der Exception-Behandlung auch noch eine Problem auftritt, dann wird hier auch nichts mehr freigegen.

Dein ShowMessage kann auch aus verschiedenen Gründen zu einer Exception führen und dann war's das mit der Code-Ausführung danach.

(Ja, ich geb zu, daß ich diese Art der Freigabe auch an einigen Stellen einsetze, aber in diesen Fällen hatte das A) seine Gründe (vorallem um noch ein paar Millisekündchen einzusparen, bei der Masse an Ausführungen) oder einfach nur wegen des kürzeren Codes und vorallem B) wußte ich, daß es in dieser Exceptionbehandlung garantiert zu keinem Problem kommen konnte (es sei denn es gibt so masive Probleme, daß das Programm sowieso gleich komplett verreckt wird).

Aber in allen anderen Fällen kann ich ebenfalls nur die Freigabe über ein zusätzliches Try-Finally empfehlen.
Vorallem da es so auch offensichtlicher wird, daß hier immer freigegeben, bzw daß dieser Code immer ausgeführt wird.

altlastenverwalter 23. Aug 2010 09:30

AW: Falsche Verwendung von try...except...end
 
Zitat:

Zitat von Bernhard Geyer (Beitrag 1044283)
Es wurde auch nicht davon gesprochen das im except-Teil die Funktion verlassen wird.

Doch. Smudo hat genau das behauptet:

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.

Zitat:

Zitat von Bernhard Geyer (Beitrag 1044283)
Wird z.B. statt einer Exption ein exit aufgerufe wird dein Code nach dem Except nicht aufgerufen, der Finally-Teil trotzdem.

Das stimmt. Exit wurde aber bisher nicht erwähnt.
Vor allem hat es nichts mehr mit Sünde 5 von shmia zu tun. Dort ERSETZT finally einfach das except und die eigentliche Fehlerbehandlung fehlt.

implementation 23. Aug 2010 11:23

AW: Falsche Verwendung von try...except...end
 
Der try-finally-Block ist ja auch nicht dazu da um Exceptions zu behandeln.
Falls im try-Block eine auftritt, bleibt sie geworfen und wird weiterhin Ebene für Ebene hochgereicht bis sie behandelt wird.
Delphi-Quellcode:
procedure Prozedur;
begin
  try
    TueWas;
  finally
    // Die Exception wird absichtlich nicht abgefangen.
    GebeResourcenFrei;
  end;
end;

...

try
  TueWas;
  Prozedur;
  TueWas;
except
  // Denn sie soll HIER behandelt werden.
  on E: EChuckNorrisIsDead do
  begin
    ...
  end;
end;
Wenn man statt dem oberen try-finally ein try-except verwendet, wird die Exception ja abgefangen.
Und das soll doch überhaupt nicht passieren.

Kieni 9. Dez 2010 14:33

AW: Falsche Verwendung von try...except...end
 
Hallo,

ich habe mal eine Frage. Ist die Verwendung von try...except im folgenden Code richtig angewandt, bzw möglich:

Code:
  If WinVer.VersionText = 'Microsoft Windows XP' then
  begin
    S:='Install .NET Framework 3.5';
    WriteLog(S);
    try
      ExecuteCommand(installDir+'\dotNet3.5.exe',SW_SHOWNORMAL,true,nil,nil);
      S:='finished at ' + DateTimeToStr(Now);
      WriteLog(S);
    except
      on E:Exception do
      begin
        Writelog('Error while installing dotNet 3.5');
        Writelog(E.ClassName+':'+E.Message);
      end;
    end;
  end;
Gruß Kieni

DeddyH 9. Dez 2010 14:40

AW: Falsche Verwendung von try...except...end
 
Das ist richtig so: wenn das ExecuteCommand fehlschlägt, dann wird der Fehler mitgeloggt.

[edit] Nachtrag: das setzt natürlich voraus, dass im Fehlerfall auch wirklich eine Exception geworfen wird ;) [/edit]

sgbSoftwareEntwickler 24. Feb 2011 08:11

AW: Falsche Verwendung von try...except...end
 
Vielen Dank für den Beitrag shmia

MephistoMyRo 24. Feb 2011 10:29

AW: Falsche Verwendung von try...except...end
 
Ich will ja nicht kleinlich sein, aber:
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;
Wenn
Delphi-Quellcode:
MachWas(Query1)
keine Exception auslöst, dann wird das hier ne Endlos-Schleife...

Delphi-Quellcode:
Query1.Next; // nächster Datensatz
müsste ein
Delphi-Quellcode:
end
weiter. Bitte korregieren oder ich hab da etwas falsch verstanden.

DeddyH 24. Feb 2011 10:34

AW: Falsche Verwendung von try...except...end
 
Wie kommst Du darauf?

Neutral General 24. Feb 2011 10:35

AW: Falsche Verwendung von try...except...end
 
Zitat:

Zitat von DeddyH (Beitrag 1084021)
Wie kommst Du darauf?

Weil das Query1.Next im except-Block steht.


Alle Zeitangaben in WEZ +1. Es ist jetzt 18:54 Uhr.
Seite 3 von 4     123 4      

Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz