![]() |
AW: Try Except Problem
Zitat:
Gruß K-H |
AW: Try Except Problem
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:
Sieht doch schick aus und wir werden niemals eine Exception sehen - GottSeiDank!
function TForm1.LoadFromFile( const AFilename : string ) : Boolean;
begin try Memo1.LoadFromFile( AFilename ); Result := True; except Result := False; end; end;
Delphi-Quellcode:
Ei, was haben wir uns da eine schöne robuste KeineExceptionWerfende Funktionalität gebaut (stundenlang-auf-die-schultergeklopfe).
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; 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:
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.
procedure TForm1.SomethingSpecial;
begin // mehrere Zeilen Code Memo1 := nil; // noch mehr Zeilen Code end; Woher sollen wir denn wissen, dass dieses Verhalten nur dann auftaucht, wenn man vorher diese oder jene Funktion ausgeführt hat, die eben dieses
Delphi-Quellcode:
ausführt?
Memo1 := nil;
Ja, woher soll man das wissen? Und was ist damit?
Delphi-Quellcode:
Keine Datei gefunden -> Fehlerdialog mit EFileNotFound erscheint, Edit1 bleibt unverändert
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; 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 ... |
AW: Try Except Problem
Zitat:
Delphi-Quellcode:
und noch beliebter ist Code ala
procedure TForm1.LoadFromFile( const AFilename : string );
begin try Memo1.LoadFromFile( AFilename ); except end; end;
Delphi-Quellcode:
try
i := StrToInt('abc'); except i := 0; end; |
AW: Try Except Problem
@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 :mrgreen: |
AW: Try Except Problem
Zitat:
|
AW: Try Except Problem
Das sollte sowieso standardmäßig aus sein und auch besser aus bleiben.
|
AW: Try Except Problem
Naja, eher sollte diese Einstellung vor Code, die sich auf die eine oder andere Richtung darauf verlässt, grundsätzlich gesetzt werden. ;-)
|
AW: Try Except Problem
Ich würde mich bei Delphi gar nicht darauf verlassen. Sonst kommt irgendein Waldschrat mal auf die Idee, das anzuschalten und dann wundert man sich doch etwas.
Ich habe mich bei Delphi jedenfalls nie darauf verlassen. |
AW: Try Except Problem
Ich hab es aufgegeben alle "Standards" selber nochmal zu setzen.
Wenn irgendein Idiot daran rumspielt, dann hat er Pech und muß mit den Konsequenzen leben. Ich bin auch dafür, daß solche Optionen endlich mal aus den Projektoptionen raus fliegen oder es zumindestens mit mindestens 200 "Willst du das wirklich?"-Dialogen bestätigen muß. |
AW: Try Except Problem
Zitat:
|
Alle Zeitangaben in WEZ +1. Es ist jetzt 17:47 Uhr. |
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