Share via

ApplicationException considered useless

  • Article

We have a guideline that bans using the ApplicationException. Here is the related excerpt from the Framework Design Guidelines:

ý Do not throw or derive from System.ApplicationException.

JEFFREY RICHTER: System.ApplicationException is a class that should not be part of the .NET Framework. The original idea was that classes derived from SystemException would indicate exceptions thrown from the CLR (or system) itself, whereas non-CLR exceptions would be derived from ApplicationException. However, a lot of exception classes didn’t follow this pattern. For example, TargetInvocationException (which is thrown by the CLR) is derived from ApplicationException. So, the ApplicationException class lost all meaning. The reason to derive from this base class is to allow some code higher up the call stack to catch the base class. It was no longer possible to catch all application exceptions..

 

Today, somebody asked me whether they should go through their code-base and remove all references to the exception. I answered that it’s not worth the effort. “ApplicationException is not considered harmful, just useless.” J

Comments

  • Anonymous
    June 23, 2006
    I might consider removing any catch blocks like so:

       catch(ApplicationException)

    since it's almost (though not quite) the equivalent to

       catch(Exception)

    If you have a lot of classes that inherit from ApplicationException.  In this case it could be harmful.

  • Anonymous
    June 24, 2006
    It's useless becouse Microsoft has not added any additional functionality inside it over plain Exception.

    For example such a common feature as retriving error message text from resources.
    On throw store only resource ID - and format them only then requested.

  • Anonymous
    June 25, 2006
    In that case, what I should use & throw for exceptions that are due to the Application?

  • Anonymous
    June 27, 2006
    remember the rule to always derive custom exceptions from ApplicationException?  so you thought...

  • Anonymous
    June 27, 2006
    The comment has been removed

  • Anonymous
    July 03, 2006
    I agree with Kalpesh,If we should not use ApplicationException or Custom Exception derive from ApplicationException then how should we throw exceptions. I have also read that throwing System.Exception is a very expensive operation and there is a lot of OS/platform specific information written,so if I have 3+ tier application where each layer bubbles the exception what should we do??

  • Anonymous
    July 05, 2006
    My last post about the ApplicationException resulted in some questions along the lines of “so, if not...

  • Anonymous
    July 05, 2006
    Kalpesh and Tim, thanks for asking. I answered your question in a new post at http://blogs.msdn.com/kcwalina/archive/2006/07/05/657268.aspx

  • Anonymous
    October 06, 2006
    A user defined Exception thrown from an COM+ object results in the following stack. Throwing an ApplicationException does work. Hence the ApplicationException should be marked as final.System.Runtime.Serialization.SerializationException: The constructor to deserialize an object of type UnitedMobile.Provisioning.eServGlobal.PI.PIException was not found. at System.Runtime.Serialization.ObjectManager.CompleteISerializableObject(Object obj, SerializationInfo info, StreamingContext context) at System.Runtime.Serialization.ObjectManager.FixupSpecialObject(ObjectHolder holder) at System.Runtime.Serialization.ObjectManager.DoFixups() at System.Runtime.Serialization.Formatters.Binary.ObjectReader.Deserialize(HeaderHandler handler, __BinaryParser serParser, Boolean fCheck, IMethodCallMessage methodCallMessage) at System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Deserialize(Stream serializationStream, HeaderHandler handler, Boolean fCheck, IMethodCallMessage methodCallMessage) at System.EnterpriseServices.ComponentSerializer.UnmarshalReturnMessageFromBuffer(Byte[] b, IMethodCallMessage msg) at System.EnterpriseServices.ComponentServices.ConvertToReturnMessage(String s, IMessage mcMsg) at System.EnterpriseServices.RemoteServicedComponentProxy.Invoke(IMessage reqMsg) at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)

  • Anonymous
    October 27, 2006
    PingBack from http://blog.sublogic.com/2006/10/python-gets-right-what-java-already-has-and-net-still-hasnt/

  • Anonymous
    January 30, 2007
    TypesShouldNotExtendCertainBaseTypes fires on types that derive from ApplicationException and DoNotRaiseReservedExceptionTypes

  • Anonymous
    May 15, 2007
    While researching on Visual Studio Static Code Analysis topics I come over blog posts by Brad Abrams

  • Anonymous
    May 16, 2007
    Помашіть ручкою ApplicationException в вашому коді. Тепер нам рекомендують кастом виключення наслідувати

  • Anonymous
    May 18, 2007
    PingBack from http://born2code.net/?p=95

  • Anonymous
    June 14, 2007
    Catch ApplicationExceptions? I was wrong!

  • Anonymous
    June 27, 2007
    I was wondering how to handle business-rules violation exceptions. Like you want to print an invoice, but the street address isn't filled in. In that case I would want, for example, to throw an InvoiceNotCompleted exception. I thought it was the right way to derive such exception from ApplicationException... But it seems not. So what should I use? For for example logging purpuses it would be nice if all business-exception would derive from a common CLR exception, specifically made for this use, without creating a custom exception, so the logging module can be reused. Any ideas on this?

  • Anonymous
    June 29, 2007
    Edwin, you should just inherit from Exception.

  • Anonymous
    July 24, 2008
    PingBack from http://www.kalivo.com/convs/show/1535-applicationexception-vs-exception-in-net

  • Anonymous
    January 15, 2009
    Does anyone know if Microsoft is planning to drop ApplicationException from the .NET Framework?  

  • Anonymous
    January 21, 2009
    PingBack from http://www.keyongtech.com/664993-creating-a-custom-exception

  • Anonymous
    February 11, 2009
    Jim, I think it won't plan to drop ApplicationException from Framework since dozens of legacy codes exists currently.

  • Anonymous
    April 10, 2009
    The comment has been removed