The Framework Class Library (FCL) defines many exception types (all ultimately derived from System. Exception). The following hierarchy shows the exception types defined in the MSCorLib.dll assem- bly; other assemblies define even more exception types. (The application used to obtain this hierarchy is shown in Chapter 23, “Assembly Loading and Reflection.”)
The 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 application-thrown exceptions would be derived from ApplicationException. This way, developers could write a catch block that catches all CLR- thrown exceptions or all application-thrown exceptions.
However, as you can see, this rule was not followed very well; some exception types are immedi- ately derived from Exception (IsolatedStorageException), some CLR-thrown exceptions are de- rived from ApplicationException (TargetInvocationException), and some application-thrown
exceptions are derived from SystemException (FormatException). 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 two types.