Exception-Fenster trotz try..except bei Lesen von Socket.Handle

[Caps]

Moin,

ich habe, kurz gesagt, einen TCP-Server mit den Sockets geschrieben, mit dem sich verschiedene TCP-Clients verbinden können sollen.

An folgender Stelle im Server möchte ich das Socket-Handle des Clients ermitteln und erhalte verständlicherweise eine Zugriffsverletzung, falls der Client in der Zwischenzeit die Verbindung geschlossen hat, daher wollte ich das abfangen wie folgt:

Delphi-Quellcode:

try
  sh := Connection.Socket.Handle;
except on e: Exception do
  ErrorList.Add('Socket-Handle konnte nicht ermittelt werden.', e.Message);
end;

Ich kompiliere das Programm und führe die EXE aus (nicht in der IDE).

Dass der try..except-Block ausgeführt wird, merke ich anhand des Eintrages in der ErrorList.
Jedoch erhalte ich ebenfalls, und das verstehe ich nicht, ein Meldungsfenster zum Wegklicken.
Das würde ich gern vermeiden, da das Programm auf einem Server eingesetzt werden soll, wo nicht ständig jemand die GUI betrachtet.

Wie kann ich das bewerkstelligen?

[Uwe Raabe]

Welche Exception zeigt denn das Meldungsfenster? Vielleicht entsteht der Fehler an ganz anderer Stelle. Das müsste man aber mit einer Debugger-Session herausbekommen.

[himitsu]

Am Socked/Connection gibt es bestimmt ein Property/Event, wo man steuern kann, dass die Meldung nicht angezeigt wird.

Hier wird aber nur auf das Handle zuegriffen, da würde ich die Exception auch woanders vermuten.
Bei den Indy gibt/gab es z.B. die Möglichkeit Exceptions anzeigen zu lassen und dann anschließend das Programm normal weiterlaufen zu lassen, so als wäre nix gewesen.

[stahli]

Soweit ich mich erinnerte hatte ich bei meinem Versuch damals (https://www.delphipraxis.net/190482-...ockettest.html) eine Nachricht (ByeByeMeldeMichAb) vom Client zum Server geschickt, bevor der Client geschlossen wurde. Der Server hat dann den Client ignoriert.

Wäre natürlich besser, wenn es eine richtige Lösung gäbe.

[Caps]

Im Ereignis OnClientError kann man das über einen var-Parameter steuern.
Aber dieses Ereignis tritt nicht ein, weil ich ja auf einen nicht mehr existierenden Socket zugreife .

Ich habe mal ein wenig verfolgt wo das hingeht. Da gibt es zunächst einen Getter GetHandle(), der die Forms-Funktion AllocateHwnd() aufruft. Das riecht mir nach Fenster, aber da kann ich ja schlecht was dran drehen.

Die Exception lautet (ugf.) Fehler bei Lesen von Adresse 00000000 oder so ähnlich.


Ich habe mittlerweile einen Workaround, indem ich im ClientDisconnect meinem Connection-Objekt den Status Disconnected gebe, dann kann ich's wenigstens abfangen, aber unpraktisch ist das mit der Exception dennoch.

Danke trotzdem!
Caps

[himitsu]

Die Exception hier abzufangen ist sowieso keine gute Lösung.
Bei dir knallt es ja, weil es nil/0 ist und damit auf den geschützten Speicher im den ersten 64K RAM zugreift,
aber wenn da ein Wert drin stünde und der auf einen Speicher zeigen würde, der zufällig eine kompatible Speicherstruktur hätte, dann würde mit einem Handle weitergearbeitet, welches falsch/ungültig ist.

[Caps]

Hm, stimmt auch wieder.

[himitsu]

Zitat:

Das riecht mir nach Fenster

Ach ja, ich schätze die Komponente arbeitet mit Window-Messages und dafür braucht man ein Fenster.

Mit AllocateHwnd kann man sich quasi ein unsichtbares MessageOnly-Window erstellen und dort einen Message-Handler registrieren,

So wie z.B. auch TApplication in der VCL Eines darstellt, um zentral SystemMessages zu empfangen.
Auch TTimer nutzt nicht das HWND seines Owners, sondern jeder Timer hat sein eigenes internes Fenster für's WM_TIMER. (ich glaub im FMX wird mir einem MultimediaTmer intern gearbeitet, da der Windows-Timer eh nicht überall verfügbar ist)