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
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 removedAnonymous
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.aspxAnonymous
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 DoNotRaiseReservedExceptionTypesAnonymous
May 15, 2007
While researching on Visual Studio Static Code Analysis topics I come over blog posts by Brad AbramsAnonymous
May 16, 2007
Помашіть ручкою ApplicationException в вашому коді. Тепер нам рекомендують кастом виключення наслідуватиAnonymous
May 18, 2007
PingBack from http://born2code.net/?p=95Anonymous
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-netAnonymous
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-exceptionAnonymous
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