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

[Bladefire]

Hallo,

gibt es eine möglichkeit, das Delphi, try except, beim ausführen mit dem debugger beachtet?

Lg Simon

[DeddyH]

Ich verstehe die Frage nicht, kannst Du etwas konkreter werden?

[Bladefire]

Code:

try
x := 1
except
x := 2

Wenn beim Debuggen ein Fehler bei "x:=1" auftritt, dann bleibt der debugger stehen und führt nicht automatisch den except teil stattdesen aus.

Ich würde es gerne haben das delphi beim debuggen automatisch den except teil hernimmt, wenn der try teil einen fehler hat.

[mkinzler]

Dann musst Du dem Debugger sagen, er soll diese(n) Exception(typ) ignorieren.

[jaenicke]

Zitat:

Zitat von Bladefire (Beitrag 1285483)

Wenn beim Debuggen ein Fehler bei "x:=1" auftritt, dann bleibt der debugger stehen und führt nicht automatisch den except teil stattdesen aus.

Ich würde es gerne haben das delphi beim debuggen automatisch den except teil hernimmt, wenn der try teil einen fehler hat.

Normalerweise möchte man beim Debuggen solche Fehler ja mitbekommen. Deshalb hält der Debugger erst einmal an. Wenn du dann fortsetzt, wird aber der Teil unter except ausgeführt, so als ob du das Programm ohne Debugger gestartet hättest.

Wenn du das nicht möchtest, kannst du wie mkinzler schon geschrieben hat den Exceptiontyp ignorieren. In einigermaßen aktuellen Delphiversionen geht das direkt in dem Dialog, den der Debugger anzeigt, in alten Versionen nur über die Optionen.

[himitsu]

Wird diese Exception denn oft ausgelöst?

Grundsätzlich wäre es besser, wenn man erstmal vermeidet, daß eine Exception überhaupt ausgelöst wird ... dann braucht man dem Debugger auch keine Ausnahme beibringen. :stupid:

Delphi-Quellcode:

try
  i := StrToInt('abc');
except
  i := 0;
end;

[Dejan Vu]

Zitat:

Zitat von himitsu (Beitrag 1285512)

Grundsätzlich wäre es besser, wenn man erstmal vermeidet, daß eine Exception überhaupt ausgelöst wird ...

Das ist mir zu grundsätzlich.
Vielleicht so: Grundsätzlich wäre es besser, wenn der happy path programmiert wird, d.h. man geht z.B. davon aus, das der String eine Zahl ist (wenn man davon ausgehen kann), die Verbindung zustande kommt, der Divisor <> 0 ist (wenn das kein Sonderfall, d.h. Bestandteil der Formel ist) usw.

Als Prüfung, ob der String eine Zahl ist, eignet sich das try-except-pattern nicht, da hast Du vollkommen recht.

Delphi-Quellcode:

// Happy Path
try
  DoThis;
  DoThat;
  C := A/B;
  Number:= StrToInt(aString);
except
  ShowMessage('This did not work properly');
end;

// Prüfung
if TryStrToInt(aString, Number) then
  Number := StrToInt(aString);
else
  ShowMessage('Cannot convert'); // Oder mach sonst irgendwas

if Not IsZero(B) then C:=A/B else c:= NaN;

if CanConnectTo(URL) then
  ConnectTo(URL)
else
  ShowMessage('Cannot connect to '+URL);

[jobo]

OT-Korinthenmodus

Zitat:

Zitat von himitsu (Beitrag 1285512)

Wird diese Exception denn oft ausgelöst?

Grundsätzlich wäre es besser, wenn man erstmal vermeidet, daß eine Exception überhaupt ausgelöst wird ... dann braucht man dem Debugger auch keine Ausnahme beibringen. :stupid:

Delphi-Quellcode:

try
  i := StrToInt('abc');
except
  i := 0;
end;

Das schreit doch nach StrToIntDef oder hast Du hier nur aus Versehen aufgehört?

@happy path (grundsätzlich)
Besonders happy wäre ich oder der Anwender vielleicht mit der Original Fehlernummer/-Meldung und einer Ausgabe der Variableninhalte, die zum Fehler geführt haben.
/OT-Korinthenmodus

[backdraft]

Ich greife das Thema nochmal auf, weil ich ein ähnliches Problem habe, mit einer Exception, die aus Indy kommt, wenn keine Verbindung aufgebaut werden kann.

Naütrlich kann ich im Debugger sagen, dass er diese Exception ignorieren soll.
Allerdings gilt es dann zum einen für alle Exceptions, wo keine Verbindung aufgebaut werden kann, zum anderen muss ich das immer auf allen Delphi Installationen neu machen.

Gibt es nicht einfach eine Compilerdirektive, wo man sagen kann "diese Exception nie an den Debugger melden"?

Gerade in Threads führt diese Exception bei mir nämlich oft dazu, dass die ganze IDE hängt, wenn ich F9 drücke.

[dummzeuch]

Nein, leider nicht. Das nervt mich auch ständig.

[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.