Why does FormatException not inherit from ArgumentException?

Question

Is there a known reason why FormatException does not inherit from ArgumentException? An invalid format would seem to be a very specific case of an argument being invalid, similar to ArgumentOutOfRangeException.

The MSDN article for the class states:

FormatException is thrown when the format of an argument in a method invocation does not match the format of the corresponding formal parameter type. For example, if a method specifies a String parameter consisting of two digits with an embedded period, passing a corresponding string argument containing only two digits to that method would cause FormatException to be thrown.

Sounds like just the scenario for an ArgumentException or deriving class to me.

All this means is that you can't deal with FormatException under the larger ArgumentException exception family, nor can you identify which parameter caused the exception to be thrown.

Is there any reason for this seemingly out-of-place exception to be where it is?

Providenciaprovident

Answer 1

FormatException is not necessarily thrown when a formal argument of a method is invalid. It can also happen if the method is consuming an external resource and the format of the data from the external resource is inappropriate.

For example, BinaryReader.Read7BitEncodedInt will throw FormatException if what it's going to read from a stream is not a valid 7-bit encoded integer. It doesn't take any arguments at all. ArgumentException, on the other hand, should only get thrown when an argument passed as a formal parameter to a method is invalid.

The description you referenced from the MSDN article is more restrictive than FormatException really is and should be clarified.

Solfeggio

That's a convincing enough argument for me. The documentation surrounding the class is plain misleading when it specifically mentions arguments in the exception's use. – Providenciaprovident

Downvoter: Care to explain? I'm wondering what's in this answer that's really "downvote-able". – Solfeggio

It's a miss-click on my part, which SO wouldn't let me undo at the time. If you edit your answer, I'd be glad to reverse it. – Providenciaprovident

@Programming Hero: That's not the first time MSDN is being misleading. To their credit, its general quality is very good and these things only happen occasionally but they do happen. – Solfeggio

I completely agree, which is why I asked the question; it's unusual for an MSDN resource to be so off-target. – Providenciaprovident

Answer 2

This is a bit snotty: but Richter in CLR Via C# (page 432) suggests that maybe it's because Exception class hierarchy wasn't implemented very well in .NET:

Microsoft's original idea was that System.Exception would be the base type for all exceptions and that two other types, System.SystemException and System.ApplicationException would be the only two types immediately derived from Exception. Furthermore, exceptions thrown by the CLR would be derived from SystemException, and all the application-thrown exceptions would be derived from ApplicationException. This way, developers could write a catch block that catches all application-thrown exceptions.

However, ... this rule was not followed very well; some exceptions are immediate derived from Exception (IsolatedStorageException), some CLR thrown exceptions are derived form ApplicationException...So it is all a big mess, and the result is that the SystemException and ApplicationException types have no special meaning at all. At this point, Microsoft would like to remove them from the exception class hierarchy, but they can't because it would break any code that already references these types.

This isn't exactly an answer to your query, but I think it is relevant because I think it indicates that there isn't really a good reason why some exception derivatives inherit the way they do. Unfortunately, the Exception class inheritance wasn't all that well thought out & it's sort of a mess.

Tabina