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 questions:

1. Performace Considerations for throwing Exceptions
2. Do you write exceptions for specific issues or general exceptions?

Answer 1

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 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

As Wheelie said, look first for an appropriate framework exception, and only use exceptions (especially custom exceptions) where you really plan to catch them.

I use a custom exception class that contains a UserMessage property, so that I can propagate the problem in plain language to the user when possible.

If you're using .NET, check out Designing Custom Exceptions. Interestingly, the documentation has changed its recommendation on the use of ApplicationException:

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. For more information, see Best Practices for Handling Exceptions.

Answer 4

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 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

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 7

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.