区分.NET异常类型

Question

为了爱所有神圣的东西,你如何在预定义的.NET异常类中区分不同的"异常风格"？

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

• 文档的根元素是NULL
• 文档中包含无效的字符
• 该文件太长了

所有这些都抛出XmlException对象和所有内部的"多告诉我一些关于这个异常"字段(如Exception.HResult,Exception.Data等)通常是空的或无效.

这Exception.Message是唯一允许你区分这些异常类型的东西,你不能真正依赖它,因为你猜对了,Exception.Message字符串是glocabilized,并且可以在文化变化时改变.至少那是我对文档的阅读.

Exception.HResult并且Exception.Data在.NET库中被广泛忽略.他们是世界.NET错误处理代码的红头发儿童.即使假设它们不是,该HRESULT类型仍然是错误代码历史中最糟糕,最彻底的最糟糕的错误代码.为什么我们在2010年仍在关注HRESULTs,这超出了我的范畴.我的意思是,如果你正在做Interop或P/Invoke这是一件事,但是...... HRESULTs在System.Exception中没有位置.HRESULTs是System.Exception的长鼻疣.

但严重的是,这意味着我必须设置许多详细的特定错误处理代码,以便找出应该作为异常数据的一部分传递的相同信息.如果他们强迫你像这样工作,例外是没用的.我究竟做错了什么？

编辑.一天后.

感谢所有的评论和回复.即使我还没有完全解决具体问题,我也在这里学习一般课程("错误消息").这是我正在使用的具体方案.

我们的应用程序使用第三方生成的XML文件.这些XML文件有时包含非法字符,这些字符实际上没有XML文件中的业务.这些非法字符会导致(验证)XmlReader炸毁"X行上的非法字符"异常".但是我们必须处理这些文件;我们不能简单地告诉用户,"抱歉,该文件没有符合官方XML规范."我们的用户甚至不知道XML是什么.

在这种情况下,Microsoft有一个官方(对我来说很奇怪)推荐(XML文档包含非法字符的情况):将文件加载到流中,迭代到包含错误的特定行(具体而言,提供, XmlException对象),并使用合法的char自定义替换有问题的char.然后尝试再次将doc加载到验证的XmlReader中,看看它是否会爆炸.这是描述该技术的知识库文章.

很好,我们正在这样做,而且它运作良好.问题是,有时我们得到的这些XML文件在其他方面都是格式错误的:它们可能是空的,它们可能缺少结束标记等等.所以如果你遵循MS建议,你实际上是在挂钩你的"替换非法字符" catch块中的逻辑,您可以捕获验证读取器抛出的原始异常.

如果异常实际上是一个"非法的char"异常,那就没问题.但如果它是"缺少根元素"或"缺少结束标记"异常,你会发现进入并替换有问题的字符本身的MS技术会爆炸,因为不仅没有违规的字符,也没有字符所有,或者有,但它们是无效的XML,或者其他什么.在这一点上,你是一个双重嵌套的捕捉内部捕获,你的头发变成灰色并且掉出来,你的眼睛是深红色,咖啡因疲劳,你正在质疑理智,更不用说实用性,使用验证读者对真实世界的XML.

所以我需要的是一种告诉,在初始catch(XmlException)块中,这是否是"缺少根元素"或"无效char"异常,所以我可以采取适当的操作.我们不能做的一件事是阻止我们的用户打开包含一些无效字符的文档.我们必须处理这些文件,我想它看起来唯一的解决方案是提前遍历文档中的每个字符,将其视为文本流而不是XML,查找非法字符,替换它们,然后使用验证的XmlReader加载该东西,如果它爆炸,我们知道它不是非法的char异常,因为我们事先剥离了非法的字符.

在此之前,我认为我至少要问1)我们可以从XmlException对象中获得更好的信息,我希望有人会告诉我2)"可以关闭XmlException.Message字符串.他们说它是本地化但是它不是真的.这个字符串在Windows的所有版本和文化中都是相同的."

但是没有人告诉过我.

Answer 1

I totally agree with you in principle, but the number of instances where I really care about the exact reason the exception was being thrown (in my code) is pretty small.

Using XmlException as an example, is there really some different behavior you would have in your code if the document was too long vs. if it had invalid characters?

The only example I can think of where I've ever really cared was for SQL type exceptions where some errors can be recovered from (e.g. a lost database connection).

ETA:

If you are worried about the culture when keying off the error message, you could just set the current thread culture to the invariant culture while you are processing the document, then set it back to the original culture when you are done. That should ensure that the message will always be the same.