try ... except trotzdem exception Popup

Philipp_Reitter · Beiträge: 430

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

Narses · Verfasst: Di 15.07.08 19:01

Moin!

Starte das Programm mal ausserhalb der IDE, geht´s dann?

cu
Narses

_________________
There are 10 types of people - those who understand binary and those who don´t.

Timosch · Beiträge: 1314 Debian Squeeze, Win 7 Prof. D7 Pers

Das Problem hatte ich auch öfter. Kann man entweder durch außerhalb der IDE starten beheben (wie schon erwähnt) oder irgendeine Einstellung bei den Projektoptionen.

PS: Was sind eigentlich "flaschen Unterforen"?

_________________
If liberty means anything at all, it means the right to tell people what they do not want to hear. - George Orwell

Boldar · Verfasst: Di 15.07.08 21:56

Timosch hat folgendes geschrieben:

PS: Was sind eigentlich "flaschen Unterforen"?

Gute Frage! :rofl:

Yogu · Verfasst: 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 · Verfasst: Mi 16.07.08 07:36

Yogu hat folgendes geschrieben:

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

Außeer selbst erzeugte, z.B.:

markieren

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

_________________
Na denn, dann. Bis dann, denn.

Tilman · Verfasst: 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.

_________________
Bringe einen Menschen zum grübeln, dann kannst du heimlich seinen Reis essen.
(Koreanisches Sprichwort)

ZeitGeist87 · Verfasst: Mi 16.07.08 10:47

Tilman hat folgendes geschrieben:

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.

Was man nicht versteht, verwendet man nicht :mrgreen:

_________________
Wer Provokationen, Ironie, Sarkasmus oder Zynismus herauslesen kann soll sie ignorieren um den Inhalt meiner Beiträge ungetrübt erfassen zu können.

Philipp_Reitter · Beiträge: 430

ok geht jetzt...
danke!

hansa · Beiträge: 3079 Erhaltene Danke: 9

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:

_________________
Gruß
Hansa

Yogu · Verfasst: 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:

markieren

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:

markieren

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

markieren

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 · Verfasst: 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*

_________________
Na denn, dann. Bis dann, denn.

Yogu · Verfasst: Mi 16.07.08 19:04

alzaimar hat folgendes geschrieben:

Exceptions werden von einer Abstratkionsstufe komplett gekapselt und nicht per raise weiter gereicht.

Du meinst also, man sollte eine Zugriffsverletzung, die aufgrund eines kleinen Bugs im Quellcode einer Fremdkomponente auftritt, einfach ignorieren? Das halte ich nicht für sehr sinnvoll...

alzaimar · Verfasst: 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.

_________________
Na denn, dann. Bis dann, denn.

	Mitgliederliste
	Gruppen
	Das Team
	Richtlinien
	Synonyme