为什么FormatException不继承自ArgumentException？

Question

FormatException 不继承自 ArgumentException 是否有已知原因？无效格式似乎是参数无效的一种非常特殊的情况，类似于 ArgumentOutOfRangeException。

该类的 MSDN 文章指出：

FormatException 当方法调用中参数的格式与相应形参类型的格式不匹配时抛出。例如，如果一个方法指定一个由两位数字和嵌入句点组成的 String 参数，则将仅包含两位数字的相应字符串参数传递给该方法将导致 FormatException抛出。

对我来说，这听起来像是 ArgumentException 或派生类的场景。

所有这一切意味着您无法处理更大的 ArgumentException 异常系列下的 FormatException，也无法识别哪个参数导致抛出异常。

有什么理由让这个看似不合适的异常出现在它的位置吗？

Answer 1

当方法的形式参数无效时，不一定会抛出FormatException。如果该方法正在消耗外部资源并且来自外部资源的数据的格式不合适，也可能会发生这种情况。

例如，BinaryReader.Read7BitEncodedInt如果要从流中读取的内容不是有效的 7 位编码整数， 将抛出 FormatException。它根本不需要任何争论。另一方面，ArgumentException 仅当作为形式参数传递给方法的参数无效时才会抛出。

您从 MSDN 文章中引用的描述比 FormatException 的实际情况更具限制性，应该予以澄清。

Answer 2

这有点傲慢：但是 Richter 在 CLR Via C#（第 432 页）中指出，这可能是因为 Exception 类层次结构在 .NET 中没有很好地实现：

Microsoft 最初的想法是，System.Exception 将成为所有异常的基本类型，另外两种类型 System.SystemException 和 System.ApplicationException< /code> 是仅有的两种直接从 Exception 派生的类型。此外，CLR 引发的异常将从 SystemException 派生，所有应用程序引发的异常都将从 ApplicationException 派生。这样，开发人员可以编写一个 catch 块来捕获所有应用程序引发的异常。

但是，...这条规则并没有得到很好的遵循；一些异常是直接从 Exception (IsolatedStorageException) 派生的，一些 CLR 抛出的异常是从 ApplicationException 派生的......所以这一切都是一团糟，结果是 SystemException 和 ApplicationException 类型根本没有特殊含义。此时，Microsoft 希望将它们从异常类层次结构中删除，但他们不能，因为这会破坏已经引用这些类型的任何代码。

这并不完全是您查询的答案，但我认为它是相关的，因为我认为它表明某些异常派生例继承它们的方式并没有真正好的理由。不幸的是，Exception 类的继承并没有经过深思熟虑。有点乱。