是否有一个已知的原因FormatException不继承自ArgumentException？无效格式似乎是参数无效的一种非常特殊的情况，类似于ArgumentOutOfRangeException.
该课程的 MSDN 文章指出：
当方法调用中的参数格式与相应形式参数类型的格式不匹配时，将引发FormatException 。例如，如果一个方法指定了一个
String由两个数字和一个嵌入句点组成的参数，那么将一个仅包含两个数字的相应字符串参数传递给该方法将导致FormatException被抛出。
听起来ArgumentException对我来说只是一个或派生类的场景。
这一切意味着你无法FormatException在更大的ArgumentException异常族下处理，也无法识别是哪个参数导致了异常被抛出。
这个看似不合时宜的例外是否有任何理由出现在哪里？
FormatException当方法的形式参数无效时，不一定会抛出。如果方法正在消耗外部资源并且来自外部资源的数据格式不合适，也会发生这种情况。
例如，如果要从流中读取的内容不是有效的 7 位编码整数，BinaryReader.Read7BitEncodedInt 则会抛出异常。FormatException它根本不需要任何论据。ArgumentException另一方面，仅当作为形式参数传递给方法的参数无效时才应抛出。
您从 MSDN 文章中引用的描述比FormatException实际情况更具限制性，应该加以澄清。
这有点不合时宜：但是CLR Via C#中的 Richter （第 432 页）表明，这可能是因为 .NET 中的异常类层次结构没有很好地实现：
Microsoft 最初的想法是，这
System.Exception将是所有异常和其他两种类型的基本类型，System.SystemException并且System.ApplicationException是唯一直接从Exception. 此外，CLR 引发的异常将派生自SystemException，并且所有应用程序引发的异常都将派生自ApplicationException。这样，开发人员可以编写一个 catch 块来捕获所有应用程序抛出的异常。但是，……这条规则并没有很好地遵守；有些异常是直接从
Exception(IsolatedStorageException)派生的，有些CLR抛出的异常是派生形式的ApplicationException……所以一切都是一团糟，结果是SystemExceptionandApplicationException类型根本没有特殊含义。此时，Microsoft 想将它们从异常类层次结构中删除，但他们不能这样做，因为它会破坏任何已经引用这些类型的代码。
这不完全是您查询的答案，但我认为它是相关的，因为我认为它表明某些异常派生类继承它们的方式并没有真正的充分理由。不幸的是，Exception 类继承并没有经过深思熟虑，而且有点混乱。