首页 > 代码库 > FtpDataStream中的隐藏问题
FtpDataStream中的隐藏问题
最近在使用FtpWebResponse.GetResponseStream方法时遇上个问题——Stream在未关闭之前就报出了ObjectDisposedException。刚开始十分困惑，因为一直用的是类似的写法，从逻辑上不应该会出现异常。之后通过ILSpy工具查看源代码以及网上找寻相关资料才找到了原因，故在此作文，以作分享。
我最初的代码是这样写的：
FtpWebRequest request = (FtpWebRequest)WebRequest.Create(param.URL);request.Credentials = new NetworkCredential(param.User, param.PassWord);request.Method = WebRequestMethods.Ftp.DownloadFile;using (FtpWebResponse response = (FtpWebResponse)request.GetResponse()){ using (StreamReader r = new StreamReader(response.GetResponseStream(), Encoding.GetEncoding("gb2312"))) { List<string> data = http://www.mamicode.com/new List();> 想法是按行读取下载的文件并保存在一个List中，以作他用。
但这段代码在读取某些文件的时候出错了， line = r.ReadLine(); 执行至此行代码时会抛出ObjectDisposedException异常。
这十分奇怪，因为从代码逻辑上看Stream在此时显然仍未被关闭。
但在查看源代码后，豁然发现我错了，FtpDataStream在读取时是会自己关闭Stream的。
FtpDataStream的Read方法源码：
public override int Read(byte[] buffer, int offset, int size){ this.CheckError(); int num; try { num = this.m_NetworkStream.Read(buffer, offset, size); } catch { this.CheckError(); throw; } if (num == 0) { this.m_IsFullyRead = true; this.Close(); } return num;}当其内部NetworkStream读取的结果为0时，其本身会自动Close。*这是FtpDataStream特有的操作方式，其它Stream不会这样做。
但如果仅是这样的话，还是无法解释异常的出现，因为若是NetworkStream读取不到字节的情况下，循环中的判断 while (line != null) 也应该能保证不再执行ReadLine操作。
那么再看Stream的ReadLine方法源码：
public override string ReadLine(){ if (this.stream == null) { __Error.ReaderClosed(); } this.CheckAsyncTaskInProgress(); if (this.charPos == this.charLen && this.ReadBuffer() == 0) { return null; } StringBuilder stringBuilder = null; int num; char c; while (true) { num = this.charPos; do { c = this.charBuffer[num]; if (c == ‘\r‘ || c == ‘\n‘) { goto IL_4A; } num++; } while (num < this.charLen); num = this.charLen - this.charPos; if (stringBuilder == null) { stringBuilder = new StringBuilder(num + 80); } stringBuilder.Append(this.charBuffer, this.charPos, num); if (this.ReadBuffer() <= 0) { goto Block_11; } } IL_4A: string result; if (stringBuilder != null) { stringBuilder.Append(this.charBuffer, this.charPos, num - this.charPos); result = stringBuilder.ToString(); } else { result = new string(this.charBuffer, this.charPos, num - this.charPos); } this.charPos = num + 1; if (c == ‘\r‘ && (this.charPos < this.charLen || this.ReadBuffer() > 0) && this.charBuffer[this.charPos] == ‘\n‘) { this.charPos++; } return result; Block_11: return stringBuilder.ToString();}此方法中不会抛出异常，但若是执行到其中的ReadBuffer方法代码，就会调用内部成员stream的Read方法，即FtpDataStream的Read方法，则可能会出现问题。
使用ReadBuffer方法的地方共有两处，第一处在完成读取文件时一定会被调用，ReadLine在此处返回null，以说明所有读取操作已经完成，不要再继续读文件。此处被执行一次且只被执行一次。（在加了类似"line != null"判断的前提下）
第二处就不一样了，如果行末是‘\r‘或\n‘字符结尾的话，则第二处ReadBuffer方法不会被执行。
若仅执行一次ReadBuffer，即只调用一次FtpDataStream的Read方法，那么即使发生最糟的结果，Stream关闭，也不会抛出异常。而如果被执行了两次，并且第一次时已读不到字节，那么由于Stream会被关闭，所以必然会出现异常。
仔细看一下 while (true) 循环中的代码，在行末不是‘\r‘或\n‘字符结尾的场合，只有ReadBuffer的返回结果是小于等于零的前提下才能退出这个循环，即FtpDataStream必定被Close。于是当最后一次读取文件时，因为必定要执行第一处的ReadBuffer方法，那么抛出异常便是无法避免的。
所以到了这里，可以大胆判断只有文件末尾没有EOL标识的才会出现因提前关闭Stream而产生的异常。（EOL指\r,\n这样的行结束标识符）
对比了下运行成功的文件与失败的文件内容，果然失败的文件末是没有\r\n的。
当找到原因后解决问题就简单多了，网上即有现成的方法，创建继承Stream的子类，然后重写ReadLine方法：
public override String ReadLine(){ try { return base.ReadLine(); } catch (ObjectDisposedException ode) { return null; }}或者更简单的改法，直接在原来的代码上加try/catch：
string line = r.ReadLine();while (line != null){ data.Add(line); try { line = r.ReadLine(); } catch(ObjectDisposedException ode) { line = null; }}如果不喜欢这样的解决方法，也可以弃用ReadLine方法，改为使用ReadToEnd方法。在读完文件后通过Split方法再保存为List。
string allData = http://www.mamicode.com/r.ReadToEnd();"\r\n" }, StringSplitOptions.RemoveEmptyEntries).ToList();
最后需要指出的是，这个问题确实是个bug，而且早在2010年就已被用户发现并提交给微软，但最终的结果是微软不会修复这个bug——
"Thank you for your feedback. You are correct, Read does call Close when it will return 0. We have examined this issue and determined that fixing it would have a negative impact on existing applications."
https://connect.microsoft.com/VisualStudio/feedback/details/594446/ftpdatastream-read-closes-stream