如果我处置其底层流，我是否需要处置 XmlReader？答案

【问题标题】：Do I need to Dispose XmlReader if I Dispose its underlying Stream?如果我处置其底层流，我是否需要处置 XmlReader？
【发布时间】：2011-03-31 20:25:02
【问题描述】：

我有以下方法 GetData 从文件创建 StreamReader。

private void GetData(string file)
{
    string filename = Path.GetFileNameWithoutExtension(file);
    XmlDocument xmldoc = new XmlDocument();

    using (StreamReader sr = new StreamReader(file))
    {
        Stream bs = sr.BaseStream;
        Stream cl = mainParser.CleanMarkup(bs);
        try
        {
            xmldoc = mainParser.LoadDocument(bs);
        }
        catch (XmlException ex)
        {
            // Exceptions are usually caused by non-compliant documents.
            // These errors are not critical to the operation of this program.
            Console.WriteLine(filename + " " + ex.Message);
        }
    }
    Msdn msdnParser = new Msdn(xmldoc);

    ListViewItem lvitem = new ListViewItem(filename);
    lvitem.SubItems.Add(filename);
    foreach (string item in msdnParser.Subitems)
    {
        lvitem.SubItems.Add(item);
    }
    listView.Items.Add(lvitem);
}

mainParser.LoadDocument(bs) 调用如下：

public XmlDocument LoadDocument(Stream file)
{
    XmlDocument xmldoc = new XmlDocument();
    XmlReader xmlread = XmlReader.Create(file);
    xmldoc.Load(xmlread);

    return xmldoc;
}

StreamReader 由GetData 处理。这是否意味着我不必处置 XmlReader，因为（我相信）这会处置其唯一的非托管资源？

【问题讨论】：

标签： c# dispose xmlreader streamreader

【解决方案1】：

最好的“经验法则”是：

如果某物实现了IDisposable，请始终将其包装在using() 块中，以确保其拥有的任何非托管资源都得到正确处置。

依靠“某物”的当前实现处理底层资源这一事实是危险的，将所有内容包装在using中并没有什么坏处，只是为了为了安全起见 =)

【讨论】：

啊，这是一个好点。这可能是我需要注意的一个概念。当一个例子出现在我面前时总是很好。
啊，答案只适用于 C#。如果答案甚至可以应用于 C++/CLI，那就太好了。

【解决方案2】：

你是对的，你不必处置读者。但在给出的代码中，它也不会受到伤害。

我不会在 LoadDocument() 中放置 using 块，因为它被设计为“借用”它的流（它不会创建它）。

但是无论如何 Dispose XmlReader 还是有争议的，只是因为它是 IDisposable。我认为这里没有明显的赢家，因为 Reader（和 Writer）家族的设计存在争议：他们在没有明确成为这些流的所有者的情况下处理了自己的 baseStreams。

【讨论】：

根据我的阅读，XmlReaderSettings 有一个属性CloseInput，默认为true。我是否应该考虑禁用此默认行为，以便在不处理底层 Stream 的情况下处理 XmlReader？
我的书骗了我。 CloseInput 的默认值为 false。