Почему FormatException не наследуется от ArgumentException?
-
22-09-2019 - |
Вопрос
Есть ли известная причина, почему FormatException
не наследуется от ArgumentException
?Недопустимый формат, по-видимому, является очень специфическим случаем недопустимости аргумента, аналогично ArgumentOutOfRangeException
.
В Статья MSDN для класса состояния:
Исключение FormatException выдается, когда формат аргумента при вызове метода не соответствует формату соответствующего типа формального параметра.Например, если метод задает
String
параметр, состоящий из двух цифр со встроенной точкой, передача соответствующего строкового аргумента, содержащего только две цифры, этому методу приведет к Исключение FormatException быть брошенным.
Звучит как просто сценарий для ArgumentException
или присвоение класса мне.
Все это означает, что вы не можете справиться с FormatException
под большим ArgumentException
семейство исключений, и вы также не можете определить, какой параметр вызвал выброс исключения.
Есть ли какая-либо причина для того, чтобы это, казалось бы, неуместное исключение оказалось там, где оно есть?
Решение
FormatException
не обязательно выбрасывается, когда формальный аргумент метода недопустим.Это также может произойти, если метод использует внешний ресурс и формат данных из внешнего ресурса является неподходящим.
Например, BinaryReader.Read7BitEncodedInt
будет бросать FormatException
если то, что он собирается прочитать из потока, не является допустимым 7-битным закодированным целым числом.Это вообще не требует никаких аргументов. ArgumentException
, с другой стороны, должен выдаваться только тогда, когда аргумент, переданный в качестве формального параметра методу, является недопустимым.
Описание, на которое вы ссылаетесь в статье MSDN, является более ограничительным, чем FormatException
действительно есть и должно быть прояснено.
Другие советы
Это немного сопливо:но Рихтер в CLR Через C# (страница 432) предполагает, что, возможно, это связано с тем, что иерархия классов исключений была не очень хорошо реализована в .NET:
Первоначальная идея Microsoft заключалась в том, что
System.Exception
будет базовым типом для всех исключений и что два других типа,System.SystemException
иSystem.ApplicationException
были бы единственными двумя типами , непосредственно производными отException
.Кроме того, исключения, создаваемые CLR, будут производными отSystemException
, и все исключения , создаваемые приложением , были бы производными отApplicationException
.Таким образом, разработчики могли бы написать блок catch, который улавливает все исключения, создаваемые приложением.Однако, ...это правило соблюдалось не очень хорошо;некоторые исключения являются непосредственными производными от
Exception
(IsolatedStorageException
), некоторые генерируемые CLR исключения являются производными от формыApplicationException
...Таким образом, все это - большой беспорядок, и в результате получается, чтоSystemException
иApplicationException
типы вообще не имеют особого значения.На данный момент Microsoft хотела бы удалить их из иерархии классов исключений, но они не могут, потому что это нарушило бы любой код, который уже ссылается на эти типы.
Это не совсем ответ на ваш запрос, но я думаю, что это актуально, потому что я думаю, это указывает на то, что на самом деле нет веской причины, по которой некоторые производные от исключений наследуются таким образом, как они это делают.К сожалению, наследование класса исключений было не так уж хорошо продумано, и это своего рода беспорядок.