About Connection closed gracefully

Connection closed gracefully
Moderately close the connection

Specified 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 wowould 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.
Many Indy component users are often troubled by the eidconnclosedgracefully exception thrown by Indy server, especially HTTP and other servers. Eidconnclosedgracefully indicates that the connection has been intentionally closed by the other party. This is different from the disconnected connection caused by a Connection reset error. If the other side has closed the connection and still reads and writes data to the socket, the Indy component will throw an eidconnclosedgracefully exception. This is similar to trying to read and write data to a file that is 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 case where Indy catches the exception, your users will never see an exception in your program unless it is run from the IDE.
In some cases, this is a real exception and you need to program it. In other cases (a typical server), this is a normal part of the protocol function, and the Indy component will handle this exception for you. Even if the Indy component captures this exception, when running in the IDE programming environment, the debugger will first trigger it. As long as you press the F9 key to continue running, the Indy component will handle this exception, but it is annoying to continuously stop running during debugging. When the Indy component captures this exception, your user will no longer see the exception prompt unless it runs in IDE.

Simple Solution
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.
For servers inherited from eidsilentexception, eidconnclosedgracefully is a normal exception. You can add eidsilentexception to the list of ignored exceptions on the language exceptions tab of "Debugger options" in the "Tools" menu. After being added to the list of ignored exceptions, the exception will still be triggered and processed in the code, but the debugger will not stop the program.

Is it an error?
Is this an error?

All except tions are not errors. includevelopers have been taught or assumed that all except tions are errors. However this is not the case, and this is why they are called except tions and not errors.
Exceptions are not necessarily errors. Many developers think that all exceptions are errors. However, this is not the case. This is why exceptions are called rather than 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 limits tions in such a way as well.
An exception is an exception. Use Delphi and C ++ builder to handle errors with exceptions. However, exceptions are used for other purposes than errors. Eabort is an example of an exception that is not necessarily an error. Such exceptions are used to adjust standard procedures and exchange information to a higher level that can be captured. The Indy component is also abnormal.

Why is it an exception?
Why is it an exception?

Attackers have commented that maybe it there shoshould be a return value to signal this condition instead of an exception. However this is the wrong approach in this case.
Many users say it should return a signal instead of an exception. However, in this case, this is an incorrect method.

The eidconnclosedgracefully is raised from a core routine, however when this routine is called it is normally several method calldeep. 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.
The eidconnclosedgracefully exception is thrown from the core loop, but when this loop is called, there are several methods that are called in depth. Eidconnclosedgracefully is actually an exception and needs to be captured by top-level callers in many cases. The correct way to handle it is to capture exceptions.

When is it an error?
When is it an error?

When eidconnclosedgracefully is raised in a client, it is an error and you shoshould trap and handle this exception.
When the client throws an eidconnclosedgracefully error, it is an error and you should capture and handle this exception.

In servers it is an exception. however sometimes it is an error, and sometimes it is an exception. for example 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.
It is an exception on the server. However, in some cases this is an error and in some cases it is an exception. For many protocols, this exception is part of the normal functions of the protocol. Because of this, if you do not capture eidconnclosedgracefully in your server code, the Indy component will capture it. It marks the connection as closed and stops all threads related to the connection. You can handle this exception in your own way. Otherwise, the Indy component will handle this exception and handle it correctly.

Why does this exception occur in servers?
Why is this exception triggered on the server?

When a client is connected to a server there are two common ways to handle the disconnection:
When a client connects to the server, there are two common ways to handle this disconnect:

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 shoshould not be raised, and if one occurs it is in fact an error and shoshould be handled.
Negotiation method-both parties agree to the disconnection of the other party through the signal, and both parties will clearly disconnect the connection. Most session protocols (such as mail and news) are disconnected in this way. When the client is about to disconnect, it will send a request to the server to tell the server that it will be disconnected. The server returns a confirmation signal indicating that the client and server are disconnected. In this case, eidconnclosedgracefully should not be triggered. If it is triggered, it is indeed an error and you must handle it.

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 shoshould be disconnected after one command and response. some of the time protocols are examples of this.
In some negotiation methods, such a request will not be sent, but both parties know when the other party will disconnect. Generally, the client connects to and sends a request, and then receives the message returned from the server. When the client does not send a clear request, the Protocol stipulates that the connection must be disconnected after the request and response. This is an example of some time protocols.

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.
Unilateral disconnection method-one party disconnects independently. The other party will detect it later and take some measures to terminate the session. Using this connection disconnect policy will cause an eidconnclosedgracefully exception, which is normal. It is an exception, but the Indy component will handle it for you. Whois is a typical example. The client connects to the server and sends a string containing its own domain name to the server Queue. The server will respond and disconnect after the response is complete. No signal is sent to the client except for the normal disconnection caused by the response.

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.
The HTTP protocol allows the preceding two methods (negotiation and unilateral disconnection). This is why eidconnclosedgracefully exceptions are often seen on the HTTP server. Both HTTP 1.0 and whois are disconnected from the server after the request is processed. The client must establish a new connection each time it requests data.

HTTP 1.1 allows a single connection to request multiple clients. 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.
HTTP 1.1 allows you to use a single connection to obtain multiple files. However, there is no command to disconnect. When the client is disconnected but the server still accepts the request, the eidconnclosedgracefully exception is triggered. For HTTP 1.1, the client is disconnected in most cases. If the server declares HTTP 1.1, it will be disconnected, but does not support the "keep connection" option.