Should I derive custom exceptions from Exception or ApplicationException in .NET?

Question

What is best practice when creating your exception classes in a .NET solution: To derive from System.Exception or from System.ApplicationException?

Anesthesiology

Answer 1

According to Jeffery Richter in the Framework Design Guidelines book:

System.ApplicationException is a class that should not be part of the .NET framework.

It was intended to have some meaning in that you could potentially catch "all" the application exceptions, but the pattern was not followed and so it has no value.

Rubeola

Incredible when one considers the Microsoft Press material for the MCTS 70-536 exam clearly says the opposite... gah! – Essential

Never fully trust MS exam books. I've read few of them - always full of errors. – Spitter

This doesn't actually answer the question. Are you saying that custom application exceptions should inherit from Exception? If so, could you say so? – Interlaminate

Answer 2

You should derive custom exceptions from System.Exception.

Even MSDN now says to ignore ApplicationException:

If you are designing an application that needs to create its own exceptions, you are advised to derive custom exceptions from the Exception class. It was originally thought that custom exceptions should derive from the ApplicationException class; however in practice this has not been found to add significant value. For more information, see Best Practices for Handling Exceptions.

http://msdn.microsoft.com/en-us/library/system.applicationexception.aspx

Persiflage

The quote does say that, but ok, edited to be more explicit. – Persiflage

Answer 3

ApplicationException considered useless is a strong, and critical, argument against ApplicationException.

Upshot: don't use it. Derive from Exception.

Hump

Yeah, Konrad has it right. On a related note: another thing thought useful (or "best practice") but really isn't is implementing ICloneable. – Dogbane

Answer 4

The authors of the framework themselves consider ApplicationException worthless:

https://web.archive.org/web/20190904221653/https://blogs.msdn.microsoft.com/kcwalina/2006/06/23/applicationexception-considered-useless/

with a nice follow-up here:

https://web.archive.org/web/20190828075736/https://blogs.msdn.microsoft.com/kcwalina/2006/07/05/choosing-the-right-type-of-exception-to-throw/

When in doubt, I follow their book Framework Design Guidelines.

http://www.amazon.com/Framework-Design-Guidelines-Conventions-Development/dp/0321246756

The topic of the blog post is further discussed there.

rp

Honoria

Answer 5

I'm used to do:

private void buttonFoo_Click()
{
    try
    {
       foo();
    } 
    catch(ApplicationException ex)
    {
      Log.UserWarning(ex);
      MessageVox.Show(ex.Message);
    }
    catch(Exception ex)
    {
       Log.CodeError(ex);
       MessageBox.Show("Internal error.");
    }
}

It allow to do the difference between:

• C# code system error that I must repairs.
• "Normal" user error that do not need correction from me.

I know it is not recommended to use ApplicationException, but it works great since there is very few classes that do not respect the ApplicationException pattern.

Wisniewski

Very few that you know about. Anyone following the Framework Design Guidelines will not be deriving from ApplicationException. If you want to maintain this pattern, then you need to create your own type like MyApplicationExcptionBase and derive all of your custom exceptions from that. BTW, the Guidelines say to create few derived exception types. – Uropod

You right: today, if I had to start from scratch, I will create a "UserError" Exception. Nevertheless, I will not refactor my old code: it is not very critique. – Wisniewski