Entwickler-Ecke :: Thema anzeigen - try ... except trotzdem exception Popup

Philipp_Reitter - Di 15.07.08 18:38
Titel: try ... except trotzdem exception Popup

hi...

ich habe schon einmal die exception in einem http post abgefangen aber mit diesem code geht's nicht:

Delphi-Quelltext

1:
2:
3:
4:
5:

    try
      Memo1.Text := http.post(Edit1.Text, parm)
    except
      posted := false;
    end;

posted wird nicht auf false gesetz und das exception fenster kommt auch :(
die exception ist Zeitüberschreitung

danke!

Mfg

Yogu - Di 15.07.08 22:32

Timosch hat folgendes geschrieben:

Das Problem hatte ich auch öfter.

Das ist kein Problem, das nennt sich Debugging ;)

Timosch hat folgendes geschrieben:

Kann man entweder durch außerhalb der IDE starten beheben

Ja, außerhalb der IDE kann man schlechter debuggen.

Timosch hat folgendes geschrieben:

oder irgendeine Einstellung bei den Projektoptionen.

(Bis Delphi 4 "Tools > Umgebungsoptionen > Debugger > Bei Exceptions anhalten"; später "Tools > Debugger-Optionen > Sprach-Exceptions > Bei Exceptions stoppen")

Die Meldung kommt, damit du den Fehler beheben kannst. ein ordentliches Programm spuckt keine Fehler aus - die müssen alle behoben werden. Und ein try ... except ist alles andere als sauber. :roll:

alzaimar - Mi 16.07.08 07:36

Yogu hat folgendes geschrieben:

...ein ordentliches Programm spuckt keine Fehler aus ...

Außeer selbst erzeugte, z.B.:

Delphi-Quelltext

1:
2:

If Not UserInputOk (sUserInput) Then
  Raise EInvalidInputException.CreateFmt('Unzulässige Eingabe',[sUserInput]);

Yogu hat folgendes geschrieben:

try ... except ist alles andere als sauber. :roll:

Da muss ich aber widersprechen. Ein Try-Except zum Zwecke der Fehlervertuschung schon, aber Exceptions sind keine Programmfehler, sondern -allgemeiner- Ausnahmen, also Ereignisse, die den normalen Programmfluss unterbrechen. Ich meine, wozu führt man denn in einer modernen Programmiersprache die Try-Except-Blöcke sonst ein? :gruebel:

Verwende Try-Except (sauber) immer dann, wenn Du Ausnahmen in für den Aufrufer (das ist in der letzten Instanz ja der Anwender) verständlichere Meldungen übersetzt. Dann überführst Du die aufrufende Klasse in einen wohldefinierten Zustand (Werte zurücksetzen etc.), damit sie nach der Ausnahme nicht 'in der Luft hängt'.

Wenn du dich mit mit einem Server verbindest, und das klappt nicht, will der Anwender z.B. kein 'Error 10053 on API-Connect' sehen, sondern eine verständlichere Fehlerbeschreibung. Weiterhin soll vielleicht ein Eintrag in einem Log (Event-Log z.B.) geschehen etc. Interne Flags ('Connected') etc. müssen zurückgesetzt, ein Wiederholungszähler (z.B. 'max. 3 Versuche') erhöht werden usw.

Exceptions sind ein integraler und sehr wichtiger Bestandteil der modernen Softwareentwicklung.

Moderiert von Narses: Delphi-Tag repariert

Tilman - Mi 16.07.08 10:46

alzaimar hat folgendes geschrieben:

Exceptions sind ein integraler und sehr wichtiger Bestandteil der modernen Softwareentwicklung.

Sehr richtig, volle Zustimmung. Verstehe diese Hexenjagd nicht, die einige auf try..except veranstalten.

Übrigens, @Yogu, was heißt denn bitte ein ordentliches Programm spuckt keine Fehlermeldungen aus, sondern diese müssen alle behoben werden? Wenn ich mit meinem Programm eine Datei laden will, dann ist es aufgabe des Programms ne Fehlermeldung zu zeigen wenn die Datei nicht existert. Das erwartet der User. Schlechte Programme zeigen gerade zu wenig und zu allgemeine Fehlermeldungen - ein gutes Programm sagt dem Anwender hingegen wo es hakt und wie er es besser machen kann.

hansa - Mi 16.07.08 13:27

Philipp_Reitter hat folgendes geschrieben:

ok geht jetzt...
danke!

Und warum geht es plötzlich ? Wer von anderen Antworten erwartet und sie selber findet, der soll sie gefälligst auch den anderen mitteilen. :idea: Glaube nicht, dass es um D4 geht. Bei D7 wäre das nämlich die Checkbox, wie gesagt -> Tools usw. Da muss bei "integrierte Fehlersuche" der Haken weg. Jetzt aber noch eine Frage von mir : wie heißt der Compiler-Schalter, um dieses Verhalten durchzuführen. Finde den nicht. :shock:

Yogu - Mi 16.07.08 18:42

Oh, da haben mich wohl einige falsch verstanden... Ich muss mich undeutlich ausgedrückt haben. :?

Yogu hat folgendes geschrieben:

Ein ordentliches Programm spuckt keine Fehler aus - die müssen alle behoben werden.

Damit meinte keine Benutzer-Fehler, sondern solche Fehler, bei denen man gerne mal die Debugger-Nachricht abschalten würde. Also zum Beispiel Fehler in Timers, Schleifen etc. Wenn du ein Datei-lässt-sich-nicht-öffnen-Fehlermeldung bekommst, dann macht doch die Debugger-Meldung nichts aus, da klickt man auf OK und lässt das Programm weiterlaufen.

Yogu hat folgendes geschrieben:

Und ein try ... except ist alles andere als sauber. :roll:

Damit meinte ich folgendes Konstrukt:

Delphi-Quelltext

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

try
  DoSomething;
  Chrash;
  WillNotBeCalled;
except
  { *leer* }
end;

Meiner Meinung gibt es zwei Arten von Except-Strukturen:

Delphi-Quelltext

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

try
  DoSomething;
  Chrash;
  WillNotBeCalled;
except
  on EExpectedError do
    { Fehler behandeln oder evtl. ignorieren }
  else
    // Alle anderen, unerwarteten Fehler melden
    raise;
end;

und

Delphi-Quelltext

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

  DoSomething;
  Chrash;
  WillNotBeCalled;
except
  on E: Exception do
    // Fehler anzeigen, loggen o.Ä.
end;

Entweder gezielt behandeln, oder Fehler melden.

alzaimar - Mi 16.07.08 19:02

Könnte man noch dran rummäkeln, aber schon besser.
*Mäkel*
Exceptions werden von einer Abstratkionsstufe komplett gekapselt und nicht per raise weiter gereicht.
Grund: Die äußere Instanz muss sich dann mit unglaublich vielen Exceptions rumärgern, nämlichen all denen, die die Programmierer aus Faulheit nicht selbst gekapselt / gelöst haben. I.a. gibt es keinen Grund, eine Exception in einem kritischen Block unbehandelt nach außen zu lassen.
Warum? Weil damit die komkrete Implementierung auch außerhalb eine Rolle spielt.
Beispiel: Datenlayer reicht eine SQL-Exception nach draußen. Toll, morgen verwenden wir keine RDBMS, sondern eine Text-Datei, die hat wieder völlig neue Exceptions, die dann mit Sicherheit außen nicht abgefangen werden. Der Entwickler hatte davon ja keine Ahnung.
*Mäkelende*

alzaimar - Mi 16.07.08 21:50

Yogu hat folgendes geschrieben:

Du meinst also, man sollte eine Zugriffsverletzung...einfach ignorieren? Das halte ich nicht für sehr sinnvoll...

Ich auch nicht. Ich habe es auch nicht behauptet. Jede Exception sollte abgefangen werden. Was dann daraus gemacht wird, bleibt Dir überlassen. Ignorieren kann sinnvoll sein, ist es i.A. jedoch nicht. Normalerweise wird man die inneren Exceptions abfangen, protokollieren und als benutzerfreundliche Exception weiter reichen. Alternativ kannst Du auch Exceptions komplett abschaffen und einen Statuswert liefern (so wie die Windows-API). Es gibt Softwarepolicies, die eine Exception als 'immer schwerwiegend' definieren, sodaß sie dann zu einem Abbruch des Programmablaufes führt: Wenn der Server nicht antwortet, dann ist eben nichts mehr zu holen.

Ein Bug in einer Fremdkomponente ist im Übrigen kein kleiner Bug, sondern eine Katastrophe. Deshalb geht man mit der Verwendung von Fremdkomponenten eher konservativ um (sollte man zumindest).

Wenn Du eine Methode verwendest, erwartest Du bestimmte Ausnahmen. Die kannst Du behandeln. Aber was macht man mit den nicht erwarteten Ausnahmen? Ich würde die Overflow-, Rangecheck-, Division-By-Zero, Nil-Pointer ... -Exceptions alle in einem einzigen Exception-Typ kapseln, mit der der Aufrufer dann wohldefiniert (weil es erwartet wird) etwas anstellen kann.

Exceptions sind eine sehr wichtige Botschaft mit klarer Aussage, und so sollen sie auch verwendet werden.

Entwickler-Ecke.de based on phpBB
Copyright 2002 - 2011 by Tino Teuber, Copyright 2011 - 2025 by Christian Stelzmann Alle Rechte vorbehalten.
Alle Beiträge stammen von dritten Personen und dürfen geltendes Recht nicht verletzen.
Entwickler-Ecke und die zugehörigen Webseiten distanzieren sich ausdrücklich von Fremdinhalten jeglicher Art!