What factors should be taken into consideration when writing a custom exception class?

Question

When are custom Exception classes most-valuable?
Are there cases when they should or should not be used? What are the benefits?

Related

Answer 1

I think the simple answer is "Create a custom exception when no existing exception adequetely expresses the exceptional situation."

I also have a second rule that I apply: "Only create a custom exception if you expect a developer to be able to handle the exception." There is no point in creating a new exception if you don't consider the exception a recoverable condition. It is more effectient to throw InvalidOperationException in that context.

EDIT: Ended up writing a blog post on this subject: http://blogs.msdn.com/jaredpar/archive/2008/10/20/custom-exceptions-when-should-you-create-them.aspx

Answer 2

When you need to distinguish one exception from the others somehow. That's it, really. Of course, you could create an exception class that takes an enum to distinguish its cause, also.

This is really easy to see when you want to pass extra information with the exception. The only reason to pass that information is if you want to be able to get that information later, and so you'll want to know the type so you can retrieve the information from that type and not others.

In C++, and perhaps some other languages, you might also typedef an exception. This would allow for type distinguishing, and possibly future conversion to a custom class.

Answer 3

I wrote a blog entry a while back about when to throw different types of exceptions, and when to create new exception types. It's not that long but is probably too long to paste here so excuse me for just linking. It should cover your question about why different exception types exist, and how to know whether you need to create a custom one.

Answer 4

I'm a bit of a minimalist and will only create a custom exception if there is calling code that must explicitly react to the particular condition that occured. For all other situations I'll use the most appropriate .NET library exception. E.g. ArgumentNullException, InvalidOperationException

Answer 5

My main reason for using custom exceptions would be encapsulation with multiple providers: having a SqlException leak out of a SqlDataAccess layer, and a SocketException out of a NetworkDataAccess layer makes calling code dependent on the particulars of your implementation. Better to wrap them into a DataAccessException or something.

Answer 6

Questions to ask yourself:

1. Who will be catching it? If no one, then you don't really need a custom exception.
2. Where will you be throwing it? Is there enough context readily available, or will you need to catch and re-throw several times before the exception is useful to the final catcher?
3. Why are you throwing it? Because you caught an exception and need to attach additional information? Because you encountered an unrecoverable error in some data, and need to communicate the specifics back to client code? Because you like throwing things?
4. What is the exception? Not what caused it but what is it from the perspective of the catcher? Something they can fix and retry? Something they should never retry? Something they should notify the user about? Something they should attach context information to and then re-throw? What determines the information you'll need to pass along, if any...

Precepts:

1. Do not waste time on custom exceptions that will never be caught.
2. Do not "double up" exceptions: each custom exception type should have a well-defined case where it can and should be caught; exceptions that don't match should be broken out into their own custom types (rather than, say, forcing the catcher to build conditional logic into a single catch() clause).
3. Unless you have a good reason not to, always allow attaching an inner exception / data from a previously-caught exception. Losing context is rarely helpful.