.NET Throwing Custom Exceptions

Question

Can anyone shed some light on the pros and cons of throwing custom exceptions (which inherit from System.Exception), or the proper way to use them? I'm already aware of the when/when not to throw exception, but I am looking for guidance on how to create my own custom exceptions.

Answer 1

Custom exceptions allow you to provide clear, meaningful exceptions, which in turn can make your library more usable, provided you use the existing exceptions whenever appropriate.

Create a custom exception any time you need to raise an exception that doesn't fit directly in the framework's exception model.

Answer 2

Use your own exceptions to flag errors which are specific to your application/domain. The advantage is that your catch blocks can filter the correct exceptions and act upon that. Use specific standard exceptions for everything else.

Answer 3

I recently wrote an entire blog entry on this particular subject:

• http://blogs.msdn.com/jaredpar/archive/2008/10/20/custom-exceptions-when-should-you-create-them.aspx

The basic summary though is ...

You should only create a new exception if you expect developers to take corrective action for the problem or to log for post mortem debugging.

Answer 4

There's actually a great series of MSDN articles on this topic:

1. Design Guidelines for Exceptions
2. Exception Throwing
3. Catching and Throwing Standard Exception Types
4. Designing Custom Exceptions
5. Choosing the Right Type of Exception to Throw

Answer 5

These are all great posts. So far I agree most with Brian Rasmussen -- create custom exceptions when you want to handle different types of specific exceptions.

Perhaps an example will help. This is a contrived example, and may or may not be useful in everyday code. Suppose you have a class responsible for authenticating a user. This class, in addition to authenticating a user, has a lock-out mechanism to lock out a user after several failed attempts. In such a case, you might design as part of the class two custom exceptions: AuthenticationFailedException and UserLockedOutException. Your AuthenticateUser method would then simply return without throwing if the user was successfully authenticated, throw AuthenticationFailedException if the user failed authentication, or throw UserLockedOutException if the user was locked out.

For example:

try
{
    myAuthProvider.AuthenticateUser(username, password);
    ShowAuthSuccessScreen();
}
catch(AuthenticationFailedException e)
{
    LogError(e);
    ShowAuthFailedScreen();
}
catch(UserLockedOutException e)
{
    LogError(e);
    ShowUserLockedOutScreen();
}
catch(Exception e)
{
    LogError(e);
    ShowGeneralErrorScreen();
}

Again, a contrived example. But hopefully it shows how and why you would want to create custom exceptions. In this case, the user of the AuthProvider class is handling each custom exception in a different way. If the AuthenticateUser method had simply thrown Exception, there would be no way to differentiate between the different reasons why the exception was thrown.

Answer 6

Why create custom exceptions?
For pros/cons of using exceptions see How to throw a good exception
Factors to consider when using custom exceptions
Best practices for creating Custom Exceptions
Creating and Throwing Exceptions