try.......except....end; - Compiler soll dies beachten

[himitsu]

Den Wunsch, programmseitig Exceptions regel zu können, hat Embarcadero NICHT vor etwas bieten zu wollen.

Ich war auch noch nicht dazu gekommen, etwas Derartiges zu bereitzustellen, (nur die Umsetzungsidee liegt irgendwo in 'ner Schublade und wartet)
vor allem, da es hier noch weitere Wünsche bezüglich des Exceptionhandlings der IDE gibt.

[dummzeuch]

Es gibt noch den Exception-Filter Expert in GExperts. Allerdings weiß ich nicht, wie gut der im aktuellen Delphi funktioniert, da ich ihn nur für Delphi 2007 und 10.2 häufiger verwende. Die Implementation ist ein ziemlicher Hack und jedes IDE-Update kann dazu führen, dass es nicht mehr funktioniert.

[TurboMagic]

Hallo,

so sehr ich den Frust verstehen kann, so denke ich kann der Debugger halt nicht wissen,
woher die Exception kommt, zumindest nicht so mit einem $IFDEF oder so.
Der Debugger müsste sich wohl den Absprungpunkt und die Exception Klasse merken für jede so zu
behandelnde Exception merken.

[Bbommel]

Das Problem ist an der Stelle (wahrscheinlich) eher Indy, das fröhlich mit Exceptions auch an Stellen wirft, an denen die nicht unbedingt nötig sind. Klassiker ist z.B. bei http, wenn noch eine Antwort gesendet werden soll, aber die andere Seite nicht mehr "zuhört". Ich finde die Stelle auf die Schnelle gerade nicht, aber wenn ich mich recht entsinne, dann steht in dem Quellcode sogar sowas wie "die Exception hier kann man eigentlich meistens ignorieren" - und ich denke mir immer: "ja, warum werft ihr sie dann?!".

An der Stelle wäre es also eigentlich aus meiner Sicht wünschenswerter, wenn man den Umgang von Indy mit Exceptions etwas ändern könnte, anstatt das Problem über die IDE zu lösen.

[jaenicke]

Zitat:

Zitat von Bbommel (Beitrag 1545252)

Klassiker ist z.B. bei http, wenn noch eine Antwort gesendet werden soll, aber die andere Seite nicht mehr "zuhört".

Dafür gibt es in den Debuggeroptionen (Tools --> Optionen --> Debugger-Optionen --> E,barcadero-Debugger --> Sprach-Exceptions) bereits den Eintrag "Indy Stille Exceptions". Wenn du den Haken setzt oder EIdSilentException dort hinzufügst, bekommst du diese intern zur Benachrichtigung verwendeten Exceptions nicht mehr in der IDE angezeigt.

Zitat:

Zitat von Bbommel (Beitrag 1545252)

Ich finde die Stelle auf die Schnelle gerade nicht, aber wenn ich mich recht entsinne, dann steht in dem Quellcode sogar sowas wie "die Exception hier kann man eigentlich meistens ignorieren"

Unit IdIOHandler --> TIdIOHandler.RaiseConnClosedGracefully

Zitat:

Zitat von Bbommel (Beitrag 1545252)

und ich denke mir immer: "ja, warum werft ihr sie dann?!".

Weil sie intern den Programmablauf steuern. Die Alternative wäre, dass man entsprechende Rückgaben einbaut, die dann geprüft werden usw., aber dadurch würde es viel mehr Ablaufsteuerungscode geben, so dass der Quelltext unübersichtlicher würde.

Ich habe Exceptions auch schon so genutzt. Das hat Vor- und Nachteile.

[Bbommel]

Zitat:

Zitat von jaenicke (Beitrag 1545260)

Zitat:

Zitat von Bbommel (Beitrag 1545252)

Klassiker ist z.B. bei http, wenn noch eine Antwort gesendet werden soll, aber die andere Seite nicht mehr "zuhört".

Dafür gibt es in den Debuggeroptionen (Tools --> Optionen --> Debugger-Optionen --> E,barcadero-Debugger --> Sprach-Exceptions) bereits den Eintrag "Indy Stille Exceptions". Wenn du den Haken setzt oder EIdSilentException dort hinzufügst, bekommst du diese intern zur Benachrichtigung verwendeten Exceptions nicht mehr in der IDE angezeigt.

Jepp, das ist bei mir auch schon seit langem aktiviert (oder ist das mittlerweile sogar Standard?). Aber guter Hinweis auf jeden Fall, ich hätte es auch nicht mehr direkt auf dem Schirm gehabt, dass es die "SilentExceptions" gibt.

Zitat:

Zitat von jaenicke (Beitrag 1545260)

Zitat:

Zitat von Bbommel (Beitrag 1545252)

Ich finde die Stelle auf die Schnelle gerade nicht, aber wenn ich mich recht entsinne, dann steht in dem Quellcode sogar sowas wie "die Exception hier kann man eigentlich meistens ignorieren"

Unit IdIOHandler --> TIdIOHandler.RaiseConnClosedGracefully

Genau die Stelle meinte ich. :-) Und die zeigt auch ziemlich gut das Problem (vielleicht auch das vom Fragesteller): da steht ja letztlich "wenn du ein Server bist, dann kannst du das hier ignorieren, wenn du ein Client bist, dann solltest du dich kümmern". Blöd ist dann, wenn man sowohl Client- als auch Server-Software schreibt, denn die IDE-Konfig ist ja nicht Projekt-Abhängig. Klar, man könnte auch wollen, dass diese Exception-Ausnahmen irgendwie pro Projekt definiert werden können, aber wenn Indy schon so ausschweifend mit Exceptions umgeht und an der Stelle sogar einen langen Kommentar im Code hat, dann baut doch wenigstens eine Möglichkeit ein, zu sagen "ich bin ein Server, lass mich in Ruhe". :-)

Zitat:

Zitat von jaenicke (Beitrag 1545260)

Zitat:

Zitat von Bbommel (Beitrag 1545252)

und ich denke mir immer: "ja, warum werft ihr sie dann?!".

Weil sie intern den Programmablauf steuern. Die Alternative wäre, dass man entsprechende Rückgaben einbaut, die dann geprüft werden usw., aber dadurch würde es viel mehr Ablaufsteuerungscode geben, so dass der Quelltext unübersichtlicher würde.

Ich habe Exceptions auch schon so genutzt. Das hat Vor- und Nachteile.

Hm, joa. Finde ich schwierig, aber müssen wir jetzt nicht im Detail diskutieren. Ich kann mir auch vorstellen, dass man, wenn Netzwerk-Bibliotheken schreibt, eh mit vielen "echten" Exceptions zu tun hat, weil es nun mal viele Stellen gibt, an denen etwas schiefgehen kann, weil irgendeine Gegenseite nicht so reagiert wie sie sollte. Wenn man dann eh "im Thema" ist, nimmt man sie vielleicht auch eher an den Stellen, wo es nicht unbedingt die beste Lösung wäre.