Rule TypesShouldNotExtendCertainBaseTypes
What about the rule on inheritance ofApplicationException not being the advised method anymore, but usingSystem.Exception as the base? The link to MSDN shows an article that tells to inherit fromApplicationException…:
Do not derive all new exceptions directly from the base classSystemException. Inherit fromSystemException only when creating new exceptions in System namespaces. Inherit fromApplicationException when creating new exceptions in other namespaces.
Microsoft's internal guidelines regarding ApplicationException have changed, though the public ones have not been updated (since I last checked).
The problem with ApplicationException is that it offers no value over the base Exception type. The old argument was that inheriting ApplicationException allows you distinguish your exceptions from ones in the framework, but that argument is meaningless because any libraries you reference, including the .NET framework itself, can also throw ApplicationException.
If you're throwing ApplicationExceptions, and all of your support libraries are throwing ApplicationExceptions, and all 3rd party ones are throwing ApplicationExceptions, you're really not in any better of shape. Because of this, the bottom line is that ApplicationException really isn't helpful for determining where an exception came from.
The only way to be absolutely sure that an exception is one of yours is to inherit your own exception type from Exception, and always use it.
The two primary problems with this rule are:
1) Old versions of FxCop pushed us to inherit ApplicationException, and this rule is the exact opposite.
2) The published design guidelines have been outdated for a very, very long time: http://msdn.microsoft.com/library/en-us/cpguide/html/cpconBestPracticesForHandlingExceptions.asp
It's rumored that the published guidelines will be updated for the 2.0 release.
-Ryan / Kardax
It is no longer a rumor but a fact: Addision-Wesley will publish an updated version of the MS Design Guidelines in the Whidbey release time-frame.
I was just looking at the finished draft the other day, and it's looking great. 8)
Michael
