ApplicationException considered useless


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 (22)

  1. Haacked says:

    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.

  2. TAG says:

    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.

  3. Kalpesh says:

    In that case, what I should use & throw for exceptions that are due to the Application?

  4. jokiz's blog says:

    remember the rule to always derive custom exceptions from ApplicationException?  so you thought…

  5. Lance says:

    What about the problem of HResult code associated with the ApplicationException vs Exception with .NET components loaded from a COM+ environment?

    Due to the mixed message about ApplicationException, I have seen a few rare cases where an exception from a CCW .NET plugin hosted from a COM+ application marshals-up as COR_E_EXCEPTION instead of COR_E_APPLICATION.

    http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconHRESULTsExceptions.asp

    Granted, this isnt a common scenario, but it can be problematic for those of us who have run into this.

    Thoughts?

  6. TimB says:

    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??

  7. My last post about the ApplicationException resulted in some questions along the lines of “so, if not…

  8. Krzysztof Cwalina says:

    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

  9. theking2 says:

    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)

  10. TypesShouldNotExtendCertainBaseTypes fires on types that derive from ApplicationException and DoNotRaiseReservedExceptionTypes

  11. While researching on Visual Studio Static Code Analysis topics I come over blog posts by Brad Abrams

  12. Помашіть ручкою ApplicationException в вашому коді. Тепер нам рекомендують кастом виключення наслідувати

  13. Catch ApplicationExceptions? I was wrong!

  14. Edwin says:

    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?

  15. Krzysztof Cwalina says:

    Edwin, you should just inherit from Exception.

  16. Jim says:

    Does anyone know if Microsoft is planning to drop ApplicationException from the .NET Framework?  

  17. WangJunwei says:

    Jim, I think it won’t plan to drop ApplicationException from Framework since dozens of legacy codes exists currently.

  18. Marc Jacobi says:

    Seems to me that the whole notion of being able to determine if its an application exception is a non-issue.

    To me, only one thing is important: are you allowed to catch it? I know this sound strange, but consider the ‘normal’ way of how exceptions are handled. catch(Exception e), right? I know you are not supposed to do it, but everybody does – including me – because its easy. This also catches a lot of exceptions that shouldn’t be caught (who is going to recover from an AccessViolationException or an ExecutionEngineException!?). So for ‘user’ code I would like to be able to do something like catch(NonCriticalException e) and *know* that I will not catch anything that should terminate the process.

    Obviously Microsoft totally screwed up on the exception hierarchy in the .NET framework. Unless they rebase these exceptions, all is lost…

    But its a good point to think about for your own application exceptions.