Many Indy users are annoyed by the EIdConnClosedGracefully exception that is raised with Indy servers, especially the HTTP and other servers. EIdConnClosedGracefully is an exception signaling that the connection has been closed by the other side intentionally. This is not the same as a broken connection which would cause a connection reset error. If the other side has closed the connection and the socket is read or written to, EIdConnClosedGracefully will be raised by Indy. This is similar to attempting to read or write to a file that has been closed without your knowledge.
In some cases this is a true exception and your code needs to handle it. In other cases (typically servers) this is a normal part of the functioning of the protocol and Indy handles this exception for you. Even though Indy catches it, when running in the IDE the debugger will be triggered first. You can simply press F9 to continue and Indy will handle the exception, but the constant stopping during debugging can be quite annoying. In the cases where Indy catches the exception, your users will never see an exception in your program unless it is run from the IDE.
Simple solution
Because the EIdConnClosedGracefully is a common exception especially with certain servers it descends from EIdSilentException. On the Language Exceptions tab of Debugger Options (Tools Menu) you can add EIdSilentException to the list of exceptions to ignore. After this is added the exceptions will still occur in the code and be handled, but the debugger will not stop the program to debug them.
Is it an error?
All exceptions are not errors. Many developers have been taught or assumed that all exceptions are errors. However this is not the case, and this is why they are called exceptions and not errors.
Exceptions are exactly that - exceptions. Delphi and C++ Builder use exceptions to handle errors in an elegant way. However exceptions have other uses besides errors as well. EAbort is one example of an exception that is not necessarily an error. Exceptions such as these are used to modify standard program flow and communicate information to a higher calling level where they are trapped. Indy uses exceptions in such a way as well.
Why is it an exception?
Many users have commented that maybe it there should be a return value to signal this condition instead of an exception. However this is the wrong approach in this case.
The EIdConnClosedGracefully is raised from a core routine, however when this routine is called it is normally several method calls deep. The EIdConnClosedGracefully is in fact an exception and needs to be trapped by the topmost caller in most cases. The proper way to handle this is an exception.
When is it an error?
When EIdConnClosedGracefully is raised in a client, it is an error and you should trap and handle this exception.
In servers it is an exception. However sometimes it is an error, and sometimes it is an exception. For many protocols this exception is part of the normal functioning of the protocol. Because of this common behavior, if you do not catch the EIdConnClosedGracefully in your server code, Indy will. It will then mark the connection as closed and stop the thread assigned to the connection. If you wish to handle this exception yourself you may, otherwise Indy will handle it and take the appropriate actions for you automatically.
Why does this exception occur in servers?
When a client is connected to a server there are two common ways to handle the disconnection:
- Mutual Agreement - Both sides agree to mutually disconnect by one side signaling (and the other optionally acknowledging) and then both sides disconnecting explicitly.
- Single Disconnect - Disconnect and let the remote side take notice.
With the Mutual Agreement method both sides know when to disconnect and both explicitly disconnect. Most conversational protocols such as Mail, News, etc disconnect in this manner. When the client is ready to disconnect it sends a command to the server telling it that it will disconnect. The server replies with an acknowledgement of the disconnect request, and then both the client and server disconnect. In these cases an EIdConnClosedGracefully should not be raised, and if one occurs it is in fact an error and should be handled.
In some cases of Mutual Disconnect no command will be issued, but both sides know when the other will disconnect. Often a client will connect, issue one command, receive the response from the server and disconnect. While no explicit command was issued by the client, the protocol states that the connection should be disconnected after one command and response. Some of the time protocols are examples of this.
With Single Disconnect, one side just disconnects. The other side is left to detect this and then take appropriate action to terminate the session. With protocols that use this disconnection method you will see EIdConnClosedGracefully and it is normal. It is an exception, but Indy knows about it and will handle it for you. The whois protocol is an example of this. The client connects to the server and sends a string containing the domain to query. The server then sends the response and disconnects when the response is finished. No other signal is sent to the client other than a normal disconnection that the response is finished.
The HTTP allows for both Mutual Agreement and Single Disconnect and this is why it is common to see the EIdConnClosedGracefully with the HTTP server. HTTP 1.0 works similar to the whois protocol in that the server signals the client simply by disconnecting after the request has been served. The client then must use new connections for each request.
HTTP 1.1 allows a single connection to request multiple documents. However there is no command to signal a disconnect. At any time, either the client or the server can disconnect after a response. When the client disconnects but the server is still accepting requests, a EIdConnClosedGracefully will be raised. In most cases in HTTP 1.1, the client is the one that disconnects. A server will disconnect when it implements part of HTTP 1.1, but does not support the keep alive option.
More!
This article is an extract from the book Indy in Depth. Indy in Depth is an e-book which you can subscribe to and receive the complete book by e-mail. Also check out the Atozed Indy Portal at www.atozedsoftware.com
About the Author
Chad Z. Hower, a.k.a. "Kudzu" is the original author and project coordinator for Internet Direct (Indy). Indy consists of over 110 components and is included as a part of Delphi, Kylix and C++ Builder. Chad's background includes work in the employment, security, chemical, energy, trading, telecommunications, wireless, and insurance industries. Chad's area of specialty is TCP/IP networking and programming, inter-process communication, distributed computing, Internet protocols, and object-oriented programming. When not programming, he likes to cycle, kayak, hike, downhill ski, drive, and do just about anything outdoors. Chad, whose motto is "Programming is an art form that fights back", also posts free articles, programs, utilities and other oddities at Kudzu World at http://www.Hower.org/Kudzu/. Chad is an American ex-patriate who currently spends his summers in St. Petersburg, Russia and his winters in Limassol, Cyprus. Chad can be reached using this form.
Chad works as a Senior Developer for Atozed Software.
