¿Por qué FormatException no hereda de ArgumentException?

Question

¿Existe alguna razón conocida por la cual FormatException no hereda de ArgumentException? Un formato no válido parecería ser un caso muy específico de un argumento que no es válido, similar a ArgumentOutOfRangeException.

Los MSDN article for the class estados:

FormatException se inicia cuando el formato de un argumento en una llamada a un método no coincide con el formato del correspondiente tipo de parámetro formal. Por ejemplo, si un método especifica un parámetro String que consta de dos dígitos con un período incrustado, pasar un argumento de cadena correspondiente que contenga solo dos dígitos para ese método provocaría que se lanzara FormatException.

Suena como el escenario para un ArgumentException o me deriva la clase.

Todo esto significa que no puede tratar con FormatException en la familia de excepciones ArgumentException más grande, ni puede identificar qué parámetro provocó la excepción.

¿Hay alguna razón para que esta excepción aparentemente fuera de lugar esté donde está?

Answer 1

FormatException no se arroja necesariamente cuando un argumento formal de un método no es válido. También puede suceder si el método consume un recurso externo y el formato de los datos del recurso externo es inapropiado.

Por ejemplo, BinaryReader.Read7BitEncodedInt arrojará FormatException si lo que va a leer de una secuencia no es un entero codificado de 7 bits válido. No toma ningún argumento en absoluto. ArgumentException, por otro lado, solo debe lanzarse cuando un argumento pasado como un parámetro formal a un método no es válido.

La descripción a la que hace referencia desde el artículo de MSDN es más restrictiva que FormatException realmente es y debe aclararse.

Answer 2

Esto es un poco estirado, pero Richter en CLR a través de C# (página 432) sugiere que tal vez es porque la jerarquía de clases de excepciones no se ejecutó muy bien en .NET:

idea original de Microsoft era que System.Exception sería el tipo de base para todas las excepciones y que otros dos tipos, System.SystemException y System.ApplicationException serían los dos únicos tipos derivados inmediatamente de Exception. Además, las excepciones arrojadas por el CLR se derivarían de SystemException, y todas las excepciones arrojadas por la aplicación se derivarían de ApplicationException. De esta forma, los desarrolladores podrían escribir un bloque catch que capture todas las excepciones arrojadas por la aplicación.

Sin embargo, ... esta regla no se siguió muy bien; algunas excepciones son inmediatas derivadas de Exception (IsolatedStorageException), algunas excepciones lanzadas de CLR se derivan de ApplicationException ... Así que todo es un gran desastre, y el resultado es que los tipos SystemException y ApplicationException no tienen ningún significado especial. En este punto, Microsoft desea eliminarlos de la jerarquía de clases de excepción, pero no pueden porque romperá cualquier código que ya haga referencia a estos tipos.

Esto no es exactamente una respuesta a su consulta, pero creo que es relevante porque creo que indica que no hay realmente una buena razón por la cual algunos derivados de excepción heredan de la forma en que lo hacen. Desafortunadamente, la herencia de la clase Exception no fue muy bien pensada & es un desastre.