为什么FormatException不从ArgumentException继承？

Question

FormatException没有从ArgumentException继承的原因是否已知？无效格式似乎是一个非常具体的参数无效的情况，类似于ArgumentOutOfRangeException。

MSDN article for the class州：

  当方法调用中的参数格式与相应的形式参数类型的格式不匹配时，抛出

FormatException 。例如，如果某个方法指定一个String参数，该参数由两个带有嵌入句点的数字组成，则将只包含两位数的相应字符串参数传递给该方法将导致抛出 FormatException 。 / p>

听起来就像ArgumentException或派生类给我的场景。

所有这些意味着您无法在较大的FormatException异常系列下处理ArgumentException，也无法确定哪个参数会引发异常。

这个看似不合时宜的例外是否有任何理由存在？

Answer 1

当方法的正式参数无效时，不一定会抛出

FormatException。如果该方法消耗外部资源并且来自外部资源的数据格式不合适，也会发生这种情况。

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

您从MSDN文章中引用的说明比FormatException更具限制性，应该澄清。

Answer 2

这有点嗤之以鼻：但是Richter在 CLR通过C＃（第432页）中表明，可能是因为异常类层次结构在.NET中没有很好地实现：

  

微软最初的想法是System.Exception将是所有异常的基本类型，而另外两种类型System.SystemException和System.ApplicationException将是从{{1}直接派生的两种类型}}。此外，CLR抛出的异常将从Exception派生，并且所有应用程序抛出的异常都将从SystemException派生。这样，开发人员就可以编写一个catch块来捕获所有应用程序抛出的异常。

     

然而，......这条规则没有得到很好的遵循;一些例外是从ApplicationException（Exception）直接派生的，一些CLR引发的异常是从IsolatedStorageException派生出来的......所以这是一个很大的混乱，结果就是{{ 1}}和ApplicationException类型根本没有特殊含义。此时，Microsoft希望将它们从异常类层次结构中删除，但它们不能，因为它会破坏任何已经引用这些类型的代码。

这不完全是你的查询的答案，但我认为它是相关的，因为我认为它表明没有一个很好的理由为什么一些异常衍生物继承他们的方式。不幸的是，Exception类的继承并没有经过深思熟虑。这有点乱。