我们有一个使用 WCF 构建的 REST API。
我们使用 WebFaultException 处理所有后端异常，如下所示：
throw new WebFaultException<string>(e.Message, HttpStatusCode.NotAcceptable);
除了我们使用流进行发布的一种情况之外，这工作得很好。
一个例子：
[WebInvoke(Method = "POST", UriTemplate = "saveUser?sessionId={sessionId}&userId={userId}",
RequestFormat = WebMessageFormat.Json,
ResponseFormat = WebMessageFormat.Json,
BodyStyle = WebMessageBodyStyle.WrappedRequest)]
[OperationContract]
string SaveUser(string sessionId, int userId, Stream stream);
当在 using 语句中处理这个流时，每当我们遇到异常时，我们都会得到：
来自提琴手：
HTTP/1.1 400 Bad Request
<p>The server encountered an error processing the request. The exception message is 'The message object has been disposed.'. See server logs for more details. The exception stack trace is: </p>
<p> at System.ServiceModel.Channels.ByteStreamMessage.InternalByteStreamMessage.get_Properties()
at System.ServiceModel.OperationContext.get_IncomingMessageProperties()
at System.ServiceModel.Dispatcher.WebErrorHandler.ProvideFault(Exception error, MessageVersion version, Message& fault)</p>
看起来这与流和 StreamReader 的处理有关。
然后我尝试删除任何会处置 StreamReader 的内容，这实际上是有效的。处理这个问题的代码现在看起来像这样：
这解决了发送正确异常消息的问题，但是如果不关闭或处置 StreamReader，这会对我们的应用程序产生多严重的影响？ 您还看到其他解决此问题的方法吗？
发生这种情况是因为 StreamReader 接管了流的“所有权”。换句话说，它让自己负责关闭源流。一旦您的程序调用 Dispose 或 Close（在您的情况下保留 using 语句范围），它也会处理源流。在您的情况下调用 sr.Dispose() 。所以文件流之后就死了。
如果您不希望这样，您可以创建一个继承自 StreamReader 的新类并重写 Close 方法；在 Close 方法中，调用 Dispose(false) ，这不会关闭流。
您还可以使用NonClosingStreamWrapper乔恩·斯基特的课程MiscUtil图书馆，它正是达到这个目的。
但最好不要在不处置 StreamReader 的情况下离开它，因为它无法清理任何非托管资源。