How do I know when to use an existing exception or write a custom exception?

Question

Thanks for contributing to this question , I decided to go ahead with making the Create () method throw exceptions , as Jon Skeet said you don’t need to handle them everywhere and just let them bubble up, seems like the best approach for larger applications.

So now I am instantiating my classes using 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, because I don’t know where to get the list of “all system exceptions” or if it’s not yet “can not instantiate the object” or if it has some other value for using it, etc. . Choosing the type of exception always seems to me such an arbitrary process, so creating my own is apparently the best idea in general.

Or am I missing something about exceptions? What other implications for deciding what type of exception to use?

Answer 1

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

Answer 2

Why create custom exceptions? explains in some detail why and when to use custom exceptions.

Answer 3

Create a new type where it may be useful to catch and find out a specific exceptional case. Is it helpful to know that the file was not found, and not the generic IO exception ?.

Answer 4

Wrote an entire blog post on this subject that may seem interesting

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

In general, do not write a custom exception class unless you really expect someone to catch and apply this type.

Answer 5

I think a good place to look for existing exceptions would be in the help file ... if you look at 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 John says, if your code does some argument checking for the Create method, you can throw an exception from ArgumentException (for example, perhaps ArgumentNonExistentEntityException if the specified identifier does not exist even though it's a bit of a mouthful).

If the exception you created does not conceptually “inherit” its value from the already existing exception, just shamelessly create a new one for your library.

Answer 6

You will create a custom exception type to provide more contextual information or values ​​for the error, otherwise you will rely on the types of runtime exceptions thrown. For example, an exception, such as a System.DivideByZero exception, may not be obvious when it bubbles up at the top of the application. Instead, you can create a custom exception to provide additional contextual information in addition to the above "DivideByZero" error.

For help on various runtime exceptions thrown, please check out the MSDN system namespace. This is not an exhaustive list, since exceptions can be thrown using native code, as well as from third-party libraries.