I know, from a lot of other questions here, that Indy TCP Server relies on exceptions to clean the connections after use.
I have a server in my hands that was coded in a way that the exceptions are handled by the code and are not re-raised for Indy.
In a ideal world, I would rewrite it to satisfy this requirement. I am, sadly, in a real world, and do not have the time nor the human resources required for such fix in a time it need to be fixed.
The server and the connection have one interesting property, however: the processing happen entirely in one OnExecute run. This means that I know for a fact that at the end of the OnExecute procedure, the connection must have been closed and it is not expected for the client to be connected yet.
So, I'm thinking of doing a simple dirty trick: At the end of the OnExecute code, instead of simply returning, I can raise a generic Indy exception, like EIdException, so that Indy catches it and do its clean process.
So, my question is if, for Indy to clean the connection, does it matter what exception is raised from OnExecute?
Can I raise EIdException, or for this case it is better to raise any other of Indy's exceptions?
Note that what I'm asking is if I can swallow all exceptions and raise a new one at the end, instead of the suggested path of re-raising the exception.
TIdTCPServer does not require an exception to be raised. IF an exception is raised, the server will catch the exception and fire its OnException event. But cleanup is performed whether or not an exception is raised. If you ensure the connection is closed properly before the OnExecute event exists, so be it. As long as you see the server firing its OnDisconnect event, then all is good.