关于Indy TIdTCPServer控件出现 connection closed gracefully 错误的处理

简单的说，当TidTCPServer调用Read方法接收数据时、或调用Write方法发送数据时，客户端主动直接断开了连接，就会触发该异常；这是正常，忽略这一错误就可以了。

Indy : Connection Closed Gracefully

Connection Closed Gracefully
Author: Chad Z. Hower
Homepage: http://www.atozedsoftware.com

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.

很多Indy组件的用户常常因为 Indy server 抛出的EIdConnClosedGracefully 异常而烦恼，特别是 HTTP 和其他的server。EIdConnClosedGracefully 是连接已经被另一方故意的关闭的象征。这与导致连接复位的错误所致的断开的连接不同。如果另一方已经关闭了连接，并且仍然向套接字中读写，Indy组件将 会抛出EIdConnClosedGracefully异常。这与您尝试向一个在您不知情的情况下被关闭的文件中读写数据是很相似的。

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.

在有些情况下这是一个真的异常，你需要编程处理它。在另外一些情况下（典型的服务器），这是协议功能的正常的一部分，Indy组件会为您处理这个异常。即 使Indy组件捕捉到了这个异常，当在IDE编程环境中运行时，调试器也将会首先触发它。你只要按F9键继续运行，Indy组件将会处理这个异常，但是在 调试期间不断的停止运行是非常烦人的。在Indy组件捕捉到这个异常的情况下，除非在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.

因为对于从EIdSilentException继承来的服务器，EIdConnClosedGracefully是一个正常的异常。您可以在 “Tools”菜单的“Debugger Options”的“Language Exceptions”选项卡中将EIdSilentException加到忽略的异常的列表中。当加到忽略的异常的列表中后这个异常仍然会在代码中触发 并被处理，但是调试器将不会停止程序的运行。

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.

异常就是异常。Delphi 和 C++ Builder 使用异常处理错误。但是异常有错误之外的其他用途。EAbort是一个异常不一定是错误的例子。这样的异常用来将标准的程序流程和交流信息调整到一个更高 的能被捕捉到的层次。Indy组件也是这样使用异常的。

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.

EIdConnClosedGracefully异常从核心循环抛出，但是当这个循环被调用时，有几种在深层调用的方法。 EIdConnClosedGracefully实际上是一个异常，并且在很多情况下需要被顶层调用者捕捉。处理它的正确的方法是捕获异常。

When is it an error?

什么时候它是一个错误呢？

When EIdConnClosedGracefully is raised in a client, it is an error and you should trap and handle this exception.

当客户端抛出一个EIdConnClosedGracefully时，它就是一个错误，您就应当捕捉并且处理这个异常。

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.

在服务器中它是一个异常。但是在有些情况下这是一个错误，有些情况下是异常。对于很多协议，这个异常是协议正常功能的一部分。因为这个，如果您在你的服务 器代码中没有捕捉EIdConnClosedGracefully，Indy 组件将会捕获它。它将会将这个连接标记为关闭，并且会停止有关这个连接的所有线程。您可以以您自己的方式处理这个异常，否则的话 Indy 组件将会处理这个异常并且为您实现正确的处理。

Why does this exception occur in servers? 

为什么这个异常会在服务器中触发？

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

当一个客户端连接到服务器上时，有两种常用的方式处理这个断开的连接：

1. Mutual Agreement - Both sides agree to mutually disconnect by one side signaling (and the other optionally acknowledging) and then both sides disconnecting explicitly.
2. 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. 

协商方式－双方都通过信号同意另一方的连接断开，并且双方都会明确的断开连接。大多数会话协议（例如Mail，News等）都是以这种方式断开连接。当客户端准备断开连接时，它将向服务器发出一个请求告诉服务器它将断开连接。服务器会返回一个同意断开连接的确认信号，然后客户端和服务器都将断开连接。在这种情况下，EIdConnClosedGracefully不应该被触发，如果被触发了，那么它就确实是一个错误，您必须处理它。

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.

单方断开连接方式－一方自主的断开连接。另一方稍后会检测到并且会采取一定的措施来终止这个会话。使用这样连接断开策略的协议将会引发EIdConnClosedGracefully异常，这是正常的。它是一个异常，但是Indy组件将会为您处理它。whois就是一个典型的例子。客户端连接到服务器并且发送一个包含自己域名的字符串到服务器队列中。服务器会回应并且在回应完毕后断开连接。除了回应导致的正常的连接断开外，没有任何信号发送给客户端。

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协议允许上述两种方式（协商方式、单方断开连接方式），这就是为什么在HTTP服务器中经常可以见到EIdConnClosedGracefully异常的原因。HTTP 1.0协议和whois都是在请求被处理后由服务端断开连接。客户端必须在每次请求数据时都要建立新的连接。

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.

HTTP 1.1允许使用一个连接获取多个文件。但是没有断开连接的命令。当客户端已经断开，但是服务端仍然接受请求时，EIdConnClosedGracefully异常就会被触发。对于HTTP 1.1，大部分情况下都是客户端断开连接。如果服务器声明了HTTP 1.1，那么它将会断开连接，但是不支持保持连接的选项。

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.