Dein
Exception-Handling schaut schon sehr "komisch" aus.
was macht das try..except mit leeren
Exception-Block?
Was soll die Prüfung auf nil im Finally?
Kommentar bekannt? Bekannt für wen? Sicherlich nicht für einen der den Code in 2 Jahren nochmal anschaut
else mit exit? Wieso nicht gleich den Rest der Funktion gleich im then-Zweig laufen lassen?
nil-Setzen vor dem try...finally - Vor dem try sollen die Konstruktoren aufgerufen werden
// #### Create IOHandler #### Das sollte jeder nach zwei Wochen Delphi wissen das hier ein Konstruktor kommt
{ Connect to the remote server } Mehrwert Kommentar? Die Methode heißt connect
Die Disconnect würde ich im try-Zweig machen. Falls dort ein Excption auftritt wird mit free noch aufgeräumt.
Delphi-Quellcode:
if PeerIPs.IndexOfName(AContext.Connection.Socket.Binding.PeerIP) <> -1 then
begin
GblUrl := PeerIPs.Values[AContext.Connection.Socket.Binding.PeerIP];
IOhnd := TIdIOHandlerStack.Create(nil);
Cli := TIdTCPClient.Create(nil);
try
Cli.IOHandler := IOhnd;
Cli.Host := GblUrl;
Cli.Port := 80;
Cli.Connect;
{ Read/Write loop }
repeat
{ Read data from Client }
if AContext.Connection.IOHandler.InputBuffer.Size > 0 then
begin
Len := AContext.Connection.IOHandler.InputBuffer.Size;
Data := AContext.Connection.IOHandler.ReadString(Len);
{ Write it to the Server }
Cli.IOHandler.Write(Data);
end;
{ Read data from Server }
if Cli.IOHandler.InputBuffer.Size > 0 then
begin
Len := Cli.IOHandler.InputBuffer.Size;
Cli.IOHandler.ReadBytes(Buf, Len, False);
{ Write it to the Server }
AContext.Connection.IOHandler.Write(Buf,Len);
{ Release system slizes }
end;
SleepEx(1, True);
Cli.CheckForGracefulDisconnect(False);
AContext.Connection.CheckForGracefulDisconnect(False);
until not AContext.Connection.Connected) or not Cli.Connected;
Cli.Disconnect;
AContext.Connection.Disconnect;
finally
Cli.Free
IOhnd.Free;
end;
end;
Windows Vista - Eine neue Erfahrung in Fehlern.