Create custom exception or use built-in exceptions?

Question

Currently I'm in the process of writing a client class that utilizes DNS, Sockets, and SSL among other classes that love to throw exceptions. Other people will be implementing this class, so I was wondering what the best practice is for throwing exceptions.

Should I create my own custom exception so they know that it is my class throwing the exception or should I allow the classes and methods I call (DNS, Sockets, etc.) to throw their own exceptions? Currently, the code is in the hundreds of lines and growing with many different method calls. What is the best practice for throwing exceptions in this situation?

Answer 1

If the BCL contains classes that already convey the meaning you want (ArgumentNullException, for instance), use those.

Reserve using your own exception classes for things that are specific to your API.

If you feel that you can add information, by all means raise your own exception but do not swallow exceptions - propagate them up as inner exceptions of your own.

Answer 2

It is fine to throw your own exceptions if they add information, but don't swallow the exceptions from the underlying services unless there is a security concern.

If you are catching one exception and and throwing a new one, assign the old one to the InnerException property of the new one. You can nest as many Exceptions as necessary in this way, which creates a hierarchical "view" into how the exception propagated, which is very helpful for debugging.

Answer 3

It really depends on your audience, i.e. the consumers of your class.

For example, if you are essentially wrapping a lot of different exceptions, it may be a good idea to create custom exceptions that would simplify the error handling in the consumer.

If you do create custom exceptions, be sure to include the original exception into the InnerException of your custom exception, unless you explicitly have a reason to hide it. This will people using your class the most information available, as well as cover you if an exception comes back that your class doesn't completely cover.

Answer 4

The worst thing you can do is throw an ApplicationException with details in the message string. IF you find yourself needing to do that, it's time for a custom exception.

Answer 5

If you want anyone to catch and recover from your exceptions, it's probably best to use a small hierarchy of custom exception types, probably organized by the expected degree of recoverability (e.g. have an exception type indicating 'something unexpected happened, but the socket is probably still good', another for 'the socket state cannot be trusted, but starting over with a new socket connection might work', and another for 'the host says what you're doing won't work; don't even bother retrying unless you have reason to believe something has changed'). The particulars of what caused an exception are often less important to the 'catching' code than the nature of the violated post-conditions.