How to know when to use an existing Exception or write a custom Exception?

Question

Thanks for the input on this question, I've decided to go with making my Create() method throw exceptions so as Jon Skeet said, you don't have to handle them everywhere and can just let them bubble up, seems the best approach for larger applications.

So now I create instances of my classes with this code:

try
{
    SmartForms smartForms = SmartForms.Create("ball");
    smartForms.Show();
}
catch (CannotInstantiateException ex)
{
    Console.WriteLine("Item could not be instantiated: {0}", ex.Message);
}

custom exception:

using System;

namespace TestFactory234.Exceptions
{
    class CannotInstantiateException : Exception
    {

    }
}

How do I know which Exception class to use?

In the above instance, I created my own Exception since I don't know where to get a list of "all system exceptions" or if there is one for "not being able to instantiate an object" yet or if it has some other meaning to use it, etc. Choosing an exception type to me has always seems such an arbitrary process, so creating my own seems to be the best idea in general.

Or am I missing something about exceptions? What other implications involved in deciding which Exception type to use?

Answer 1

Create a new type when it might be useful to be able to catch and know a specific exceptional case occured. Is it useful to know that a File wasnt found rather than a generic IO exception ?.

Answer 2

If the reason you can't create the object is because the argument to Create was invalid, you should probably throw an ArgumentException. However, you could always create our own class derived from ArgumentException if you really want to be able to handle that kind of exception separately to others. (Are you sure you want to?)

Answer 3

http://stackoverflow.com/questions/417428/why-create-custom-exceptions explains in pretty good detail why and when to use the custom exceptions.

Answer 4

Wrote an entire blog post on this subject that you may find interesting

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

In summary, don't write a custom exception class unless you actually expect someone to both catch and act on the type.

Answer 5

I think a good place to find existing exceptions would be in the help file... if you look up the help for the Exception class, there should be a list of derived classes on the overview page.

How to decide whether to create a new one (derived from Exception), or inherit from an existing one depends on what the exception means.

As Jon says, if your code does some validation on the argument to the Create method, you may want to make an exception derived from ArgumentException (for example maybe an ArgumentNonExistentEntityException if the specified ID does not exist although that is a bit of a mouth full).

If the exception you are creating does not conceptually 'inherit' its meaning from an exception that already exists, just unashamedly create a new one for your library.

Answer 6

You will create a custom exception type to provide more contextual information or meaning to the error otherwise you will rely on the runtime generated exception types. For instance an exception like System.DivideByZero exception may not be obvious when it bubbles up to the top in an application. Instead, you could create a custom exception to provide more contextual information in addition to the above 'DivideByZero' error.

For reference on the different runtime generated exceptions, please have a look at MSDN's system namespace. This is not an exhaustive list since exceptions can be generated by native code and also from third party libraries.