Microsoft changes it’s ApplicationException stance
May 11th, 2007[ Geek ]
It’s been a while since exceptions cropped up here. While this isn’t ‘hot off the presses’, I’m certainly just catching up. When the boys at Microsoft originally built the .NET framework, they added a base exception class named ApplicationException. They suggested, and illustrated themselves in any related example they wrote, that custom exceptions in your application should extend from this instead of the base Exception:
“User applications, not the common language runtime, throw custom exceptions derived from the ApplicationException class. The ApplicationException class differentiates between exceptions defined by applications versus exceptions defined by the system.”
If you read past that paragraph then you’ll discover that this class is essentially a dead class now:
“If you are designing an application that needs to create its own exceptions, you are advised to derive custom exceptions from the Exception class. It was originally thought that custom exceptions should derive from the ApplicationException class; however in practice this has not been found to add significant value.”
Of course they don’t go out of their way to explain why there isn’t “significant value”, however, Brad Abrams does here. Actually the explanation is in the post comments:
“When first reading Mr. Richters advice on not using ApplicationException I was stunned, but it actually make sense. If you create some application specific exceptions you may want to derive these exceptions from a common base class in order to be able to catch them all in a single catch clause. Deriving this common exception from ApplicationException doesn’t add anything useful to your exception hierarchy – it just deepens it.”
Basically MS deepened the exception hierarchy without adding ANY value which is rule #something of designing quality custom exceptions:
“Designing exception hierarchies is tricky. Well-designed exception hierarchies are wide, not very deep, and contain only those exceptions for which there is a programmatic scenario for catching. We added ApplicationException thinking it would add value by grouping exceptions declared outside of the .NET Framework, but there is no scenario for catching ApplicationException and it only adds unnecessary depth to the hierarchy. You should not define new exception classes derived from ApplicationException; use Exception instead. In addition, you should not write code that catches ApplicationException.”