Exception Class: When to Derive from it, In C# (.Net)?

Question

I am continuing with my exam revision.

I have come across the usage of the Base Exception class and I have seen it on exam papers also.

My question is when do you derive from the Base Exception class?

I am of the impression if you want a custom class to throw an exception with more meaningful information, then you can create a custom exception class that contains the exact data that is representative of how your custom class is used and what scenario it is designed to be used for?

Why can't my custom exception class derive from 'ApplicationException' or 'SecurityException' or the base 'Exception' class?

I am of the impression that I should derive from the base Exception class and not the previous two.

My question second is, when would you derive from the other two??? Are there any clear-cut distinctions as to when you would derive from either one of these three? Assuming there are no others I have I have missed out?

SMALL UPDATE:

This question from transcender pretty much hits the nail on the head.

---

*Which class should you use to generate an application-specific exception?

Answer: The ApplicationException class*

Answer 1

Ideally, exceptions should be grouped in a hierarchy such that if code will want to handle several exceptions the same way, they will all be derived from a common base class. If the base throw-able type had been an interface rather than a class, such an ideal might have been somewhat achievable. As it is, however, the single-inheritance limitation for classes severely limits the usefulness of the hierarchy.

The only time an exception hierarchy is apt to be a useful concept is when an implementation of an interface, or a new version of a class, which is documented as throwing certain exceptions wants to allow code to distinguish among more distinct conditions than are reported by those exceptions. In such a scenario, having a method throw exceptions which do not derive from the documented ones would be a breaking change, so one must throw an exception that inherits from the documented one which best describes the previously-unanticipated condition. That's rather ugly, but the exception-handling mechanism doesn't really provide any better alternative. It's rather unfortunate that things like IEnumerator<T>.MoveNext() aren't documented as throwing any exception which would simply mean "Sorry--the system isn't on fire or anything, and I don't know that anybody's changed the collection, but I can neither advance to the next item nor truthfully say the enumeration is complete", but they don't.

Other than the case where one needs to throw an exception that's compatible with existing code, it may be helpful to have the exceptions used by an application or library derive from a common base. Instead of using ApplicationException it should be something like YourApplicationNameException or YourLibraryNameException--something that nothing else is apt to derive from. Something like ApplicationException is bad because code which does a catch ApplicationException will get not only the exceptions which it derived from that type, but also any exceptions which any other libraries derived from it.

Answer 2

In our most recent project we used a base exception class. We used it to get the following functionality:

• All exceptions needed a number, so defining the property for the number was done in the base class
• All exception messages needed to be formatted the same way, with the number, reason and type. This get formmated message was done in the base class.

Our base exception class derives from ApplicationException. This may have been a mistake, there is a lot of discussion about problems with too much depth of inheritance. However, we have not had any problems with this.

One tip for the exam: Read the question very carefully. Good luck.

Answer 3

In general, you want to derive from the Exception class which most closely resembles the type of exception you want to throw. If the trouble is that some Argument or Parameter has been passed which causes a problem, use ArgumentException. If you need some customization with that, inherit from ArgumentException.

In my experience, the only two reasons to use the base Exception are: 1) when you need some custom exception that completely does not fit one of the current exception models or 2) When a method could theoretically throw a number of exceptions, but you've already caught the ones you find most likely to be thrown.

Typically, I don't inherit from exceptions at all. Simply setting the Message property tends to be enough.

Answer 4

This is all discussed in the Design Guidelines document.