如果 XmlException.SourceUri 是只读的，那有啥好处？

Posted 2023-02-26

【中文标题】如果 XmlException.SourceUri 是只读的，那有啥好处？

【英文标题】：If XmlException.SourceUri is read-only, what good is it?如果 XmlException.SourceUri 是只读的，那有什么好处？

【发布时间】：2011-02-19 15:10:32

【问题描述】：

我的代码中有几个地方抛出一个新的 System.Xml.XmlException 似乎是合适的。我可以这样做

throw new XmlException("Your XML sucks go fix it then try again.");  

但我认为最好尽可能利用特定于异常类的成员（否则你不妨每次都抛出一个普通的 ol'Exception）。 SourceUri 和 LineNumber 会有所帮助，但它们只有有 get 方法，我无法为它们赋值！只有 3 个构造函数重载，并且它们都没有这些成员的参数；我只能初始化Message，没有别的。

必须有一些方法来用值填充这些数据成员，否则为什么 XmlException 会打扰它们？

我想我可以创建一个继承 XmlException 的新类并编写一个初始化 SourceUri 等的新构造函数，但仍然必须有一种方法可以只使用 XmlException。对吧？

【参考方案1】：

那里是a constructor with the line number and line position。我看不到任何需要 SourceUri 的东西......

我相信您可以使用序列化流上下文填充它 - 但那将非常脆弱。

我认为最好将其视为仅由系统抛出的 XmlExceptions 有效提供的东西。我不认为这让它变得毫无用处——只是不如它可能的灵活。 （我怀疑世界上抛出的绝大多数 XmlException 是由系统而不是用户代码抛出的。）

【讨论】：

是的，如果流上下文确实改变了 SourceUri 的值，那可能更像是一个安全漏洞而不是功能。

【参考方案2】：

有一个带有sourceUri参数的构造函数：

internal XmlException(string res, string[] args, string sourceUri)

但由于它是内部的，它只能在 System.Xml 程序集中调用。无论如何，我认为您不应该自己抛出XmlException。此异常通常由与 XML 相关的 BCL 类引发。您应该创建自己的异常并抛出它。

【讨论】：

好的，在这种情况下，内部构造函数是有意义的。当然我可以从 XmlException 继承，然后我可以访问protected 成员。

【参考方案3】：

我用Reflector看了一下，似乎只有两个构造函数设置了SourceUri。这些是反序列化，以及设置所有内容的单个内部构造函数，但所有公共构造函数都调用它，并将 SourceUri 设置为 null。显然，这些都不能轻易访问。我会得出结论，没有设置 SourceUri 属性的好方法。