To throw exceptions, I usually use built-in exception classes, e.g. ArgumentNullException
and NotSupportedException
. However, sometimes I need to use a custom exception and in that case I write:
class SlippedOnABananaException : Exception { }
class ChokedOnAnAppleException : Exception { }
and so on. Then I throw and catch these in my code. But today I came across the ApplicationException
class – should I be using that instead? What's it for?
It does seem inefficient to have lots of effectively identical Exception classes with different names (I don't usually need any individual functionality). But I dislike the idea of catching a generic ApplicationException
and having to use extra code to determine what the error was.
Where should ApplicationException
fit in with my code?
Best Answer
The short answer is: nowhere.
It is a relic of the past, where Microsoft intended developers to inherit all their custom exceptions from ApplicationException. Shortly after, they changed their mind and advised that custom exceptions should derive from the base Exception class. See Best Practices for Handling Exceptions on MSDN.
One of the more widely circulated reasons for this comes from an exerpt from Jeffery Richter in Framework Design Guidelines:
So there you have it. The executive summary is that ApplicationException is not harmful, just useless.