.net - 区分 .NET 异常类型

Question

出于对所有神圣事物的热爱，您如何区分预定义的 .NET 异常类中的不同“异常风格”？

例如，一段代码可能会抛出 XmlException在以下条件下:

文档的根元素为NULL

文档中的字符无效

文档太长

所有这些都被抛出为 XmlException对象和所有内部“告诉我有关此异常的更多信息”字段(例如 Exception.HResult 、 Exception.Data 等)通常为空或 null。

那留下 Exception.Message作为唯一允许您区分这些异常类型的东西，您不能真正依赖它，因为您猜对了， Exception.Message字符串是全局化的，并且可以在文化改变时改变。至少这是我在 documentation 上的阅读.
Exception.HResult和 Exception.Data在 .NET 库中被广泛忽略。他们是世界 .NET 错误处理代码的红发继子。即使假设它们不是， HRESULT type 仍然是错误代码历史上最糟糕、最令人讨厌的错误代码。为什么我们仍然关注 2010 年的 HRESULT，这超出了我的理解。我的意思是，如果您正在执行 Interop 或 P/Invoke，那是一回事，但是... HRESULT 在 System.Exception 中没有位置。 HRESULT 是 System.Exception 长鼻上的一个问题。

但说真的，这意味着我必须设置许多详细的特定错误处理代码，以便找出应该作为异常数据一部分传递的相同信息。如果异常(exception)强制你这样工作，它们就毫无用处。我做错了什么？

编辑。一天后。

感谢所有的评论和回复。即使我还没有完全解决具体问题，我也在这里学习了一般性类(class)(“错误消息很糟糕”)。这是我正在处理的特定场景。

我们的应用程序使用第三方生成的 XML 文件。这些 XML 文件有时包含非法字符，这些字符实际上与 XML 文件无关。这些非法字符导致(验证中的)XmlReader 因“X 行非法字符”异常而崩溃。然而，我们必须处理这些文件；我们不能简单地告诉用户，“对不起，该文件没有符合官方 XML 规范。”我们的用户甚至不知道什么是 XML。

在这种情况下(XML 文档包含非法字符的情况)，Microsoft 有一个官方(对我来说很奇怪)建议:将文件加载到流中，迭代到包含错误的特定行(具有讽刺意味的是，在XmlException 对象)，并用合法字符自定义替换有问题的字符。然后尝试再次将文档加载到验证 XmlReader 中，看看它是否会崩溃。这是 Knowledge Base article描述技术。

很好，我们正在这样做，而且效果很好。问题是有时我们得到的这些 XML 文件在其他方面格式不正确:它们可能是空的，它们可能缺少结束标记等。因此，如果您遵循 MS 的建议，您实际上是在 Hook “替换非法字符”逻辑进入 catch 块，您可以在其中捕获验证读取器抛出的原始异常。

如果异常实际上是“非法字符”异常，那很好。但是，如果是“根元素丢失”或“结束标记丢失”异常，您会发现进入并替换有问题的字符本身的 MS 技术会爆炸，因为不仅没有有问题的字符，而且在全部，或者有，但它们是格式无效的 XML，或者其他什么。在这一点上，你处于双重嵌套的陷阱中，你的头发变灰并脱落，你的眼睛因咖啡因疲劳而变成深红色，你在质疑它的理智，更不用说效用了使用针对真实世界的 XML 验证读者。

所以我需要的是一种在初始 catch(XmlException) 块中告诉我们这是“缺少根元素”还是“无效字符”异常的方法，以便我可以采取适当的措施。我们不能做的一件事是阻止我们的用户打开包含一些无效字符的文档。无论如何我们都必须处理这些文档，我想唯一的解决方案是提前遍历文档中的每个字符，将其视为文本流而不是 XML，找到非法字符，替换它们，然后使用验证 XmlReader 加载事物，如果它爆炸，我们知道这不是非法字符异常，因为我们事先剥离了非法字符。

在这样做之前，我想我至少会问 1) 我们能否从 XmlException 对象中获得更好的信息，我希望有人能告诉我 2) “可以关闭 XmlException.Message 字符串。他们说它是本地化的，但是不是真的。这个字符串在所有版本和文化的 Windows 中都是相同的。”

但没有人告诉过我。

Answer 1

原则上我完全同意你的看法，但是我真正关心抛出异常的确切原因(在我的代码中)的实例数量非常少。

以 XmlException 为例，如果文档太长与包含无效字符，您的代码中真的会有一些不同的行为吗？

我能想到的唯一一个我真正关心的例子是 SQL 类型异常，其中一些错误可以从中恢复(例如丢失的数据库连接)。

预计到达时间:

如果您在关闭错误消息时担心文化，您可以在处理文档时将当前线程文化设置为不变文化，然后在完成后将其设置回原始文化。这应该确保消息始终相同。