FormatExceptionから継承しない既知の理由はありArgumentExceptionますか? 無効な形式は、 のように、引数が無効な非常に特殊なケースのように見えますArgumentOutOfRangeException。
クラスのMSDN記事には次のように記載されています。
メソッド呼び出しの引数の形式が、対応する仮パラメーターの型の形式と一致しない場合、FormatExceptionがスローされます。たとえば、メソッドが
Stringピリオドが埋め込まれた 2 桁で構成されるパラメーターを指定する場合、2 桁のみを含む対応する文字列引数をそのメソッドに渡すと、FormatExceptionがスローされます。
ArgumentExceptionまたは派生クラスのシナリオのように思えます。
これが意味することは、より大きな例外ファミリFormatExceptionの下では対処できないこと、また例外がスローされる原因となったパラメーターを特定できないことです。ArgumentException
この一見場違いな例外がどこにあるのか、何か理由はありますか?
FormatExceptionメソッドの仮引数が無効な場合にスローされるとは限りません。メソッドが外部リソースを消費していて、外部リソースからのデータの形式が不適切な場合にも発生する可能性があります。
たとえば、ストリームから読み取ろうとしているものが有効な 7 ビットでエンコードされた整数でない場合BinaryReader.Read7BitEncodedInt にスローします。FormatException引数はまったく必要ありません。ArgumentException一方、メソッドに仮パラメーターとして渡された引数が無効な場合にのみスローされる必要があります。
MSDN の記事から参照した説明は、実際よりも制限的でFormatExceptionあり、明確にする必要があります。
これはちょっと気取った話ですが、Richter in CLR Via C# (page 432) は、例外クラス階層が .NET でうまく実装されていないことが原因ではないかと示唆しています。
Microsoft の最初のアイデアは、それ
System.Exceptionがすべての例外の基本型であり、他の 2 つの型でSystem.SystemExceptionありSystem.ApplicationException、Exception. さらに、CLR によってスローされる例外は から派生しSystemException、アプリケーションによってスローされるすべての例外は から派生しApplicationExceptionます。このようにして、開発者は、アプリケーションによってスローされたすべての例外をキャッチする catch ブロックを作成できます。しかし、... このルールはあまり守られていませんでした。
Exception一部の例外は( )から直接派生しIsolatedStorageException、一部の CLR スローされた例外はフォームから派生しApplicationExceptionます ...したがって、すべてが非常に混乱し、その結果、SystemExceptionandApplicationException型には特別な意味がまったくありません。この時点で、Microsoft はそれらを例外クラス階層から削除したいと考えていますが、これらの型を既に参照しているコードが壊れてしまうため、できません。
これはあなたの質問に対する正確な答えではありませんが、一部の例外派生物がその方法を継承する正当な理由がないことを示していると思うので、関連性があると思います。残念ながら、Exception クラスの継承はあまりよく考えられていませんでした。