> If you are having to implement workarounds all the time, then you are
> probably not using it the way it was designed to be used to begin with.
Remy, I code the way the online tutorials teach. Not the way you know. Sorry
but if I was upto your standard of coding I would do things the better way.
My point is I'm just trying to show another easier (and easy to understand)
way of solving the problem.
>If you keep getting "Connection closed gracefully" exceptions, then you
>need to
> take a deeper look at why you are accessing the sockets after they have
> been
> closed.
I don't access the sockets after they are closed. All my write operations go
through a write procedure which checks if the TCP client is connected - if
not it exits. I've received this error when my Client has disconnected. If
you type the error into Google you'll find many other people get it too.
>> Besides, Richard stated that he currently disconnects the client
>> FROM the SERVER.
>
> He's disconnecting from both ends.
Fair point, I didn't notice that to be honest.
> Which is not technically wrong.
So why does the client raise the error then? - If you disconnect from the
server, the client needs the try/except in any read or write situation to
avoid that really annoying error message.
> But under most situations, the server code should not be calling
> Disconnect().
> Only the client should be.
I understand that but sometimes you want to forcefully disconnect a client -
EG if they are not authorised to connect etc.
> Calling ReadLn() on the client side does not help the situation.
You are right - I forgot he is only writing and not reading lol. I suppose
he could simply put his WriteLn statement into the try/except clause instead
which would protect him from the error message when closing.
> And you should not be using try..except blocks just to hide arbitrary
> exceptions without good
> cause anyway.
I would say Indy being a pain in the grass is a good cause..
I've known many people have problems with this error - it's a pain because
the server also suffers from the pesky error message too. It can be hard to
get to the bottom of this error sometimes and frequently it doesn't even
seem to have a cause. The easiest and most effective way is to put Read and
Write into the try/except clause. That way you don't need to worry to much
as it's handled and ignored. I know it is not the perfect 'Remy'
method/standard but it does do the job for us less experienced programmers
and is effective at stopping that really annoying error message.
> That just serves to hide errors in your own code that leads
> to the exceptions being thrown in the first place.
Yes/No lol, because like I said above, I've had the same error on the server
side in the past too. Only way of dealing with it (after much hunting on
google & finding many others in the same boat) is to use a try/except clause
for read/write operations. I know it's not perfect but like I said above, it
stops that pesky message being shown and is the simplest way of dealing with
it.
I've had problems in my own application where after my Client disconnects it
still shows the "Connection Closed Gracefully" message even though the
client disconnected itself. I could find absolutely no reason for the
application to still attempt a write operation (I always use the "If
TCPClient.Connected" method so it will only write IF connected). There
seemed to be no reason for it attempting to write other than TCPClient
wanting to do so for some strange reason. I introduced the try/except clause
and that was the end of the problem.
