Try Except Problem

[jaenicke]

Wenn das Laden fehlschlägt, sollte der Pfad sicherlich auch nicht angezeigt werden:

Delphi-Quellcode:

procedure TForm1.OpenDialog1BitBtnClick(Sender: TObject);
begin
  {$BOOLEVAL OFF}
  if OpenDialog1.Execute and LoadFile(OpenDialog1.Filename) then
    Edit1.Caption := OpenDialog1.FileName;
end;

[Bernhard Geyer]

Zitat von jaenicke:

Wenn das Laden fehlschlägt, sollte der Pfad sicherlich auch nicht angezeigt werden:

Delphi-Quellcode:

procedure TForm1.OpenDialog1BitBtnClick(Sender: TObject);
begin
  {$BOOLEVAL OFF}
  if OpenDialog1.Execute and LoadFile(OpenDialog1.Filename) then
    Edit1.Caption := OpenDialog1.FileName;
end;

Mit Booleval wird aber auf jedenfall die LoadFile-Methode ausgeführt auch wenn diese über einen alten Wert in OpenDialog1.Filename aufgerufen würde (z.B. Letzte Verwendung). Ich bin mir nicht sicher ob im abgebrochenen Zustand der String leer ist.

[Sir Rufo]

Wie geht man mit Exceptions um?

Wenn man die behandeln kann, dann und nur dann nimmt man einen try except . Ansonsten macht man sich das Verhalten einer Exception zunutze (alle Anweisungen danach werden nicht mehr ausgeführt):

Delphi-Quellcode:

procedure TForm1.LoadFileButtonClick( Sender : TObject );
begin
  if OpenDialog1.Execute then
  begin
    Memo1.LoadFromFile( OpenDialog1.Filename );
    Edit1.Text := OpenDialog1.Filename;
  end;
end;

Wenn jetzt Memo1.LoadFromFile( OpenDialog1.Filename ); eine Exception auslöst, dann wird Edit1 nicht verändert und es erscheint der Dialog mit der Fehlermeldung.

Ist es das Verhalten, was gesucht wird?

Und komisch, das bekommt man ohne diese seltsame Schnickschnack Programmierung. Und irgendwie ist es auch noch einfacher.

Das Herumfuhrwerken an Exceptions und das Erstellen von Wrapper-Methoden, die im Fall der Fälle dann statt einer Exception einen bestimmten Rückgabewert liefern, führt meistens nur zu wesentlich mehr und unlesbarem Code und in 99% aller Fälle dazu, dass Programmierfehler unentdeckt bleiben.

Exceptions sind nicht der Feind, aber das Abfangen ohne wirkliche Behandlung ist der erste Schritt um die Anwendung zu meinem Feind zu machen.

Ja ich höre schon wieder die Stimmen "aaaaaber, ...". Natürlich kann man Exceptions abfangen, aber eben nur wenn man diese auch behandeln kann. Ohne sinnvolle Behandlung ist nur noch ein erneutes Werfen sinnvoll, wobei hier auch eine Übersetzung bzw. Umleitung auf eine eigene Exceptionklasse erfolgen kann.

Delphi-Quellcode:

MyConnection.StartTransaction;
try
  MyQueryA.ExecSQL;
  MyQueryB.ExecSQL;
  MyConnection.Commit;
except
  MyConnection.Rollback;
  raise;
end;

[p80286]

Zitat von Sir Rufo:

Wie geht man mit Exceptions um?

Wenn man die behandeln kann, dann und nur dann nimmt man einen try except . Ansonsten macht man sich das Verhalten einer Exception zunutze (alle Anweisungen danach werden nicht mehr ausgeführt)

Danke, daß Du das mal so klar ausgeführt hast. Meist finde ich nur Beschreibungen wie man mit Exceptions umgeht, aber nicht warum. Das muß sich der geneigte Benutzer oftmals selbst erarbeiten, und die Überprüfung der eigenen Erkenntnisse scheitert an wolkigen Aussagen, die mehr verschleiern als erklären.

Gruß
K-H

[Sir Rufo]

Der falsche Umgang mit Exceptions (ich bezeichne das gerne als eine lethale Exception-Phobie) führt zu den interessantesten Problemen, die nur durch aufwändigstes Debugging zu beheben sind:

Delphi-Quellcode:

function TForm1.LoadFromFile( const AFilename : string ) : Boolean;
begin
  try
    Memo1.LoadFromFile( AFilename );
    Result := True;
  except
    Result := False;
  end;
end;

Sieht doch schick aus und wir werden niemals eine Exception sehen - GottSeiDank!

Delphi-Quellcode:

procedure TForm1.LoadFileButtonClick(Sender : TObject );
begin
  if OpenDialog1.Execute then
  begin
    if LoadFromFile( OpenDialog1.Filename ) then
      Edit1.Text := OpenDialog1.Filename
    else
      ShowMessage( 'Datei nicht gefunden ' + OpenDialog1.Filename );
  end;
end;

Ei, was haben wir uns da eine schöne robuste KeineExceptionWerfende Funktionalität gebaut (stundenlang-auf-die-schultergeklopfe).

Irgendeine Knalltüte (in 99% der Fälle, ist man das sogar selber) hat uns aber irgendwo in den Code folgende Zeile eingebaut:

Delphi-Quellcode:

procedure TForm1.SomethingSpecial;
begin
  // mehrere Zeilen Code
  Memo1 := nil;
  // noch mehr Zeilen Code
end;

Jetzt wird keine Datei mehr geladen selbst wenn es die Datei gibt und die Anwendung behauptet in der Meldung steif und fest, dass es diese Datei nicht gibt. Ich wünsche eine fröhliche Fehlersuche, wenn der Anwender mitteilt, dass keine Datei mehr geladen wird. Natürlich behaupten wir - wegen unsere unfehlbaren Methode - dass es diese Datei dann eben auch nicht gibt. Und wir testen das Laden bis zum Erbrechen und werden keinen Fehler finden und natürlich den Anweder einfach als DAU abstempeln.

Woher sollen wir denn wissen, dass dieses Verhalten nur dann auftaucht, wenn man vorher diese oder jene Funktion ausgeführt hat, die eben dieses Memo1 := nil; ausführt?

Ja, woher soll man das wissen?

Und was ist damit?

Delphi-Quellcode:

procedure TForm1.LoadFromFile( const AFilename : string );
begin
  Memo1.LoadFromFile( AFilename );
end;

procedure TForm1.LoadFileButtonClick(Sender : TObject );
begin
  if OpenDialog1.Execute then
  begin
    LoadFromFile( OpenDialog1.Filename );
    Edit1.Text := OpenDialog1.Filename;
  end;
end;

Keine Datei gefunden -> Fehlerdialog mit EFileNotFound erscheint, Edit1 bleibt unverändert
Memo1 ist nil -> Fehlerdialog mit EAccessViolation erscheint, Edit1 bleibt unverändert

Suchst du noch oder hast du den Fehler schon behoben ...
bzw.
Diskutierst du noch mit dem Anwender oder suchst du schon den Fehler ...

[himitsu]

Zitat von Sir Rufo:

Der falsche Umgang mit Exceptions (ich bezeichne das gerne als eine lethale Exception-Phobie) führt zu den interessantesten Problemen, die nur durch aufwändigstes Debugging zu beheben sind:

Delphi-Quellcode:

function TForm1.LoadFromFile( const AFilename : string ) : Boolean;
begin
  try
    Memo1.LoadFromFile( AFilename );
    Result := True;
  except
    Result := False;
  end;
end;

Sieht doch schick aus und wir werden niemals eine Exception sehen - GottSeiDank!

Noch "besser" ist nur

Delphi-Quellcode:

procedure TForm1.LoadFromFile( const AFilename : string );
begin
  try
    Memo1.LoadFromFile( AFilename );
  except
  end;
end;

und noch beliebter ist Code ala

Delphi-Quellcode:

try
  i := StrToInt('abc');
except
  i := 0;
end;

[Sir Rufo]

@himitsu

Bei so einem Code sollte einem eigentlich augenblicklich die Gicht in die Finger fahren. Mal sehen ob sich das mit einer IDE-Erweiterung realisieren lässt

[p80286]

Zitat von himitsu:

Delphi-Quellcode:

try
  i := StrToInt('abc');
except
  i := 0;
end;

@nicht nur Himitsu
Wenn die 0 als Fehler definiert ist und alle Datensätze gelesenwerden müssen, egal ob gültig oder nicht, und die Anwendung nicht dialoglastig ist, dann ist so ein Konstrukt nicht ganz falsch.

Gruß
K-H

[jaenicke]

Zitat von Bernhard Geyer:

Mit Booleval wird aber auf jedenfall die LoadFile-Methode ausgeführt

Nein, denn ich habe die vollständige Auswertung ja aus- und nicht angeschaltet.

[himitsu]

Das sollte sowieso standardmäßig aus sein und auch besser aus bleiben.