Try..except in Entwicklungsumgebung

Weide · Beiträge: 61

Hallo,

ist es normal, dass eine Try... except Anweisung nur funktioniert, wenn man die EXE außerhalb der Entwicklungsumgebung startet? Innerhalb der Entwicklungsumgebung (also gestartet mit F9) wird eine Try... except Anweisung bei mir nicht abgefangen, was mich etwas nervt.

Gruß Weide

LCS · Verfasst: Mo 25.11.02 14:05

Hi
Unter Tools-Debugger Optionen kannst du auf der Seite "Sprach-Exceptions" das Anhalten bei Delphi Exceptions abstellen.

Gruss Lothar

_________________
Der BH ist für die Brust, der Plan ist für'n Ar...

Gast Erhaltene Danke: 1

@Weide

Also ich will jetzt nicht großkotzig wirken, aber eigentlich bräuchte ich keine Try/Except. Ich kann mich nicht drann erinnern, wann ich das letzte mal eine Fehlermeldung bekamm die von Try/Except gemeldet wurde. Ich baue sie zwar ein, weil ich nicht perfekt bin, aber ich fange noch in der Entwicklung alle Fehler ab. Das kann ich machen weil ich die Fehlermeldungen noch in der Entwickungszeit bekomme. Am Anfang habe ich die auch mal abgestellt, bis ich dann ein Programm mal produziert habe, das zwar keine Fehler meldete, aber falsche Ergebnisse lieferte.

Seit dem weiss ich:

Mit Try/Except programmiert man nicht.

Wenn du in der Entwicklungszeit nicht die richtigen Fehlermeldungen bekommst, dann wirst du die Fehler auch nicht ausmerzen können.

Hier ein kleines Beispiel das zeigt was ich meine. Du kannst es mal mit der alten Einstellung testen und mit der Neuen (die keine Fehlermeldungen ausgibt). Beachte bitte das Ergebnis:

markieren

Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:

function Test(a, b: Integer): Integer;
begin
  try
    result := a div b
  except
    ShowMessage( 'Fehler' );
  end;
end;

procedure TForm1.Button1Click(Sender: TObject);
begin
  ShowMessage(IntToStr( Test(5, 0) ));
end;

Jetzt sag mir wo der Fehler liegt.

Udontknow · Beiträge: 2596 Win7 D2006 WIN32, .NET (C#)

Es sei noch mal angemerkt, daß man Exceptions nicht dazu mißbrauchen sollte, verschiedene erwartete Zustände im Programm zu bearbeiten.

Cu,
Udontknow

Udontknow · Beiträge: 2596 Win7 D2006 WIN32, .NET (C#)

Da war einer schneller... :wink:

Obwohl die Aussage "Mit Try .. Except programmiert man nicht" nun doch ein wenig übertrieben ist. So fängt man nun mal unerwartete Fehler ab. Und die eigentliche Exception kann man sich ja trotzdem ausgeben lassen, ohne aber nun irgendwelche Schleifen zu verlassen:

markieren

Quelltext

1:
2:
3:
4:
5:
6:

try
  ...
except
  On E:Exception do
    Memo.Lines.Add(E.Message);
end;

Cu,
Udontknow

Gast Erhaltene Danke: 1

Mit "Mit Try/Except programmiert man nicht" meine ich nicht, daß man keine Try/Except nutzen darf, sondern, daß man sie nicht mißbauchen sollte. Ganz krass wäre das:

markieren

Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:

function Test(a, b: Integer): Integer; 
begin 
  try result := a div b except end; 
end; 

procedure TForm1.Button1Click(Sender: TObject); 
begin 
  ShowMessage(IntToStr( Test(5, 0) )); 
end;

DivByZero kriegt man garnicht mit, nur das Ergenbnis ist ein wenig anders als es sein sollte.

Was ich meine ist das:

markieren

Quelltext

1:
2:
3:
4:
5:
6:
7:
8:

procedure TForm1.Button1Click(Sender: TObject);
begin
  try
    Memo1.Lines.LoadFromFile('c:\AbcText.txt');
  except
    ShowMessage( 'Fehler! Datei nicht gefunden.' );
  end;
end;

Mit Try/Except programmiert man nicht.

Das ist besser:

markieren

Quelltext

1:
2:
3:
4:
5:
6:
7:

procedure TForm1.Button1Click(Sender: TObject);
begin
  if not FileExists('c:\AbcText.txt') then begin
    ShowMessage( 'Fehler! Datei nicht gefunden.' );
    Exit;
  end else Memo1.Lines.LoadFromFile('c:\AbcText.txt');
end;

Ganz ohne Try/Except. Mann kann fast alles vorher abfragen.

markieren

Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:

function Test(a, b: Integer): Integer; 
begin 
  if b <> 0 then result := a div b else begin
    ShowMessage( 'Fehler! DivByZero.' );
    //Irgendwie drauf reagieren
  end;; 
end; 

procedure TForm1.Button1Click(Sender: TObject); 
begin 
  ShowMessage(IntToStr( Test(5, 0) )); 
end;

Weide · Beiträge: 61

Hallo,

vielen Dank erstmal für Eure Hinweise :-)

Hmm, ich weiß nicht, ob ich nun ein try.... except missbrauche. Ich frage ein Eingabefeld ab (String) und wandle diesen Wert dann in ein TDate-Wert(try). Falls er sich nicht wandeln lässt (except), gebe ich eine Fehlermeldung heraus und fordere zur Korrektur auf. Das Ganze geht innerhalb einer try... except mit wenigen Programmzeilen. Ich könnte natürlich auch den Eingabestring "auseinanderpflücken" um zu untersuchen, ob alles seine Richtigkeit hat, aber das würde mit Sicherheit mehr Aufwand in Anspruch nehmen. Da war mir ein einfaches try... except eleganter - dazu ist es doch auch meiner Meinung nach da, oder nicht?

Gruß Weide

Udontknow · Beiträge: 2596 Win7 D2006 WIN32, .NET (C#)

Ja, das ist ein Mißbrauch.
Es geht auch ohne try/except: StrToIntDef heisst das Zauberwort.

Cu,

Udontknow

Weide · Beiträge: 61

Hallo nochmal,

wenn man mit StrToInt beispielsweise als Tag eine 34 konvertiert oder als Monat ein 14, erfolgt keine Fehlerwertausgabe, beim anschließenden "EncodeDate" ohne try...except schon ;-)

Gruß Weide

Udontknow · Beiträge: 2596 Win7 D2006 WIN32, .NET (C#)

Wie Popov bereits gesagt hatte: Du musst deine eigenen Plausibilitäsprüfungen machen.

Aber jetzt rate mal, was für eine Funktion es für Datekonvertierung gibt:
Ja, genau ! StrToDateDef.

Cu,
Udontknow

Weide · Beiträge: 61

ok ok, ich gebe mich geschlagen .... und bleibe bei meiner try... exept Anweisung ;-)

(weil ich nicht begreife was daran so schlimm ist, sie zu "missbrauchen").

Das mit der StrToDateDef war mir aber neu (und taucht bei mir in der Hilfe auch nicht auf (Delphi6 Ent.), vielen Dank.

Gruß Weide

Udontknow · Beiträge: 2596 Win7 D2006 WIN32, .NET (C#)

Zitat:

weil ich nicht begreife was daran so schlimm ist, sie zu "missbrauchen").

Kurz und bündig gehalten: Benutze keine Try/Except-Blöcke, damit du nicht beim Debuggen immer wieder durch erwartete Exceptions gestört wirst.

Cu,
Udontknow

Klabautermann · Verfasst: Mo 25.11.02 18:48

Hallo,

Udontknow hat folgendes geschrieben:

Kurz und bündig gehalten: Benutze keine Try/Except-Blöcke, damit du nicht beim Debuggen immer wieder durch erwartete Exceptions gestört wirst.

ich will auch mal

.

Fange jeden Fehler den du dir vorstellen kannst ab (Durch Werüberprüfungen, überprüfungen auf existenz von Dateien usw.). Wenn du das getahn hast dann Packe das ganze noch einmal in eine TRY EXCEPT Anweisung um die Fehler abzufangen die du dir nicht vorstellen kannst. Bei jedem Fehler egal ob aktiv (mit IF) oder passiv (TRY EXCEPT) abgefangen solltest du etwas definiertes tun, also z.B. eine Fehlermeldung ausgeben und nicht einfach weiterarbeiten, da das folgefehler verursacht.

Das hat die vorteile das du 1. geziehlter auf die Fejler reagieren kannst und 2. anfängst sauberer zu Programmieren, da du nicht so viele Fehlerbehandlungen schreiben willst :mrgreen:

.

Ein Datum würde ich übrigens nicht über ein Edit-Feld entgegennehmen sondern z.B. über einen DateTimePicker, da dieser Fehleingaben abfängt und den user (vieleicht sogar DAU) die Bedienung des Programms einfacher macht (indem er z.B. das Datumsformat aufzeigt).

Gruß
Klabautermann

Weide · Beiträge: 61

Hallo Klabautermann und alle,

ich wollte doch nur wissen, wie man eine try... except Anweisung in der entwicklungsumgebung behandelt *heul*

Spaß beiseite, vielen Dank erstmal für Eure Hilfe und für die Tipps. Klabautermann, der tipp mit dem DatePicker ist sehr gut - man sollte vielleicht doch mal inensiver die Komponentenleiste durchforsten.

Aber (JA, ich reite immer noch auf meiner try..except Anweisung herum ;-)

):

Es heißt hier immer wieder, man sollte versuchen, möglichst alle Ausnahmen vorher abzufangen. Dann sagt Klabautermann, zum Schluss doch noch eine try ...except um vielleicht vergessenes Abzufangen - das macht auch durchaus Sinn - finde ich. Aber wenn es mir (wie in meinem Fall) sch...egal ist, was genau denn nu! falsch ist, dann macht ein (im Gegensatz zu try..except) aufwändiges Abfangen der möglichen Fehler überhaupt keinen Sinn. Ich will lediglich wissen, DASS was falsch ist - mehr nicht. Ein sinnloses (IMHO) Abfangen sämtlicher Vorkommnisse macht das Programm nur unübersichtlicher - und ob das so die feine englische Art ist ...?

Gruß Weide

tommie-lie · Beiträge: 4373 Ubuntu 7.10 "Gutsy Gibbon"

darum geht's aber gar nicht.
Klabautermann sagt nur, daß man vorher gucken kann, welche Probleme auftreten könnten. Zum Beispiel vor dem Öffnen von Dateien gucken, ob sie da ist. Und wenn es nur so etwas banales wie eine Datei ist, die fehlt, wäre der Anwender sichelrihc glücklich, wenn er nicht gleich zum Support-o-Phne greifen muss, sondern weiß "Aha, mir fehlt Datei xyz.ext." und sich ins Netz begiebt und nach dieser Datei ausschau hält.
Wenn dann noch andere Probleme auftreten (zum beispiel die Datei schreibgeschützt ist), die man nicht vorhersehen kann (gut, Schreibschutz kann man vorhersehen, schlechtes Beipsiel) macht man dann noch eien Try aussenrum, damit sich das PRogramm nicht mitten in der Ausführung eienr wichtigen Operation (Backup o.ä.) verabschiedet.
Und nur dazu sollte Try/Except verwendet werden: Zum aussortieren von nicht vorhersehbaren Fehlern.

Nebenbei: Ich benutze auch nie Try/Except, weil ich auch immer vorher gucke, was der Anwender von mir will und dementsprechend überprüfen, ob das, was er will, auch so gemacht werden kann.

_________________
Your computer is designed to become slower and more unreliable over time, so you have to upgrade. But if you'd like some false hope, I can tell you how to defragment your disk. - Dilbert

Gast Erhaltene Danke: 1

@Weide

Ich will nicht behaupten, daß ich ein Engel bin. Manchmal ist es mir auch Shitegal und ich will auch nur so schnell wie möglich das Ergebnis. Da hab ich auch keine große Lust auf "unnötige", aber vor allen komplizierte, Überprüfungscodes. Manchmal macht die Überprüfung mehr Arbeit als der Rest. Dann mache ich das hier:

markieren

Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:

function IsDateError(S: String): Boolean;
var
  d: TDate;
begin
  Result := True;
  try d := StrToDate(S) except Result := False end;
end;

procedure TForm1.Button1Click(Sender: TObject);
var
  d: TDate;
begin
  if IsDateError(Edit1.Text) then d := StrToDate(Edit1.Text);
end;

Eine Überprüfungsfunktion. Ist sehr simpel und schnell gemacht. Ist das aber nicht das gleiche in grün? Jajn. Zuest bleibt mein Code sauber. Ich hab vor dem Zuweisen (hier als Beispiel das Datum) überprüft ob der Edit Text auch ein Datum enthällt. In der Button1 Prozedur ist kein Fehler drinn, nur meine Überprüfungsfunktion ist *mist*e. Wenn das Programm läuft, ich Zeit habe und anfange alles zu optimieren, dann kommt auch die IsDateError Funktion drann. Dann kommt Try/Except raus und ich mache eine richtige Überprüfung.

Wie gesagt, ich mache die Überprüfungen meistens sofort, da sie kaum Zeit in Anspruch nehmen. Allerdings will ich nicht widersprechen, daß manchmal die Überprüfung viel Arbeit macht. Dann mache ich den kleinen Trick.

Außerdem hat die Methode ein Vorteil

. Sollte irgendwer später dein Code sehen und sagen: "Hej, das ist aber kein guter Programmierstil", dann kannst du immer noch sagen: "Ja, die Überprüfung hab ich ausgelagert. Die hab ich vergessen zu optimieren". Wenn du aber diese Try/Except Überprüfung mitten im "richtigen" Code machst, dann wird dir das keiner abnehmen.

Weide · Beiträge: 61

Hallo,

nochmals vielen Dank an alle und ..... ich werde mir Eure Ratschläge zu Herzen nehmen und ab sofort try...execpt mit Bedacht verwenden - versprochen.

Gruß Weide

PS: So, nun werde ich noch ein paar GoTo-Anweisungen schreiben ;-)

Tino · Beiträge: 9839 Erhaltene Danke: 45 Windows 8.1 Delphi XE4

Weide hat folgendes geschrieben:

So, nun werde ich noch ein paar GoTo-Anweisungen schreiben ;-)

Das war hoffentlich nur ein Witz :-D

patrick · Beiträge: 1481 WIN2k, WIN XP D6 Personal, D2005 PE

also ich verarbeite grundsätzlich sehr viel try exept blöcke da man
A: immer mit unvorhergesehenen dingen rechenen muss.
B: keine für den user cryptische, undefinierte fehlermeldungen bekommt.
C: mit try...except ist man immer auf der sicheren seite

_________________
Patrick
im zweifelsfall immer das richtige tun!!!

Gast Erhaltene Danke: 1

Ja, nur warum mit Try/Except arbeiten wenn es nicht sein muß. Um beim Beispiel zu bleiben: warum LoadFromFile in ein Try Block setzen wenn man auch vorher abfragen kann ob die Datei auch das ist.

	Mitgliederliste
	Gruppen
	Das Team
	Richtlinien
	Synonyme