Try Except Problem

[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

[himitsu]

Doch, ist es.

Versuch mal soeinen Code zu debuggen und außerdem sind Exceptions eher für Ausnahmen und nicht zur "normalen" Programmsteuerung gedacht.
Val, TryStrToInt, StrToIntDef usw.

[Sir Rufo]

Zitat von 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

Ja wenn die Welt so einfach wäre ... und niemand diese Funktion anders definieren könnte, dann ja, aber dem ist nicht so, da diese Funktion eben doch auf einmal aus einer anderen Unit kommt, dort fehlerhaft ist und eigentlich eine Exception wirft und ich diese Information nie bekomme, weil ich toll alle Exceptions wegfange.

Niemals eine Exception blind wegfangen, sondern eher an so vielen Stellen wie möglich sogar eine Exception werfen, wenn die übergebenen Informationen so nicht verarbeitbar sind. Nur so kann ich eine zuverlässige und robuste Anwendung erstellen mit möglichst wenigen Bugs.

[mm1256]

Zitat von Sir Rufo:

Niemals eine Exception blind wegfangen, sondern eher an so vielen Stellen wie möglich sogar eine Exception werfen, wenn die übergebenen Informationen so nicht verarbeitbar sind. Nur so kann ich eine zuverlässige und robuste Anwendung erstellen mit möglichst wenigen Bugs.

Wahre Worte und mir aus der Seele gesprochen

[Dejan Vu]

Und wenn man dann noch in Abstraktionsebenen denkt und Exceptions der aufgerufenen niedrigeren Abstraktionsebene abfängt, interpretiert und (abstrakter) weiterleitet, hat man einen Securitymanagement um sein Subsystem gelegt, mit dem sich schon recht komplexe und leicht zu wartende große Systeme implementieren lassen.

Mit Subsystem ist hier ist die Menge von Klassen in enger Kopplung gemeint, die sich gemeinsam um die Lösung eines Problemkomplexes kümmern.

Ein Beispiel ist der Communication-Layer, der die konkreten TCP- RDBMS- oder Streamexceptions abfängt, interpretiert (u.U. sogar repariert) und ggf. als 'CommunicationException' weiterleitet. Den Aufrufer interessiert es nämlich nicht, ob das gerade ein TCP-Timeout oder ein RDBMS-Lesefehler infolge explodierter Platten ist: Die Kommunikation funktioniert nicht, und das reicht ihm.