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

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.