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

Published 23 June 06 02:17 by kcwalina

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS

Comments

# Haacked said on June 23, 2006 6:15 PM:
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.
# TAG said on June 24, 2006 5:04 PM:
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.
# Kalpesh said on June 25, 2006 10:00 AM:
In that case, what I should use & throw for exceptions that are due to the Application?
# jokiz's blog said on June 27, 2006 9:15 AM:
remember the rule to always derive custom exceptions from ApplicationException?  so you thought...
# Lance said on June 27, 2006 3:03 PM:
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?




# TimB said on July 3, 2006 8:36 PM:
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??
# Krzysztof Cwalina said on July 5, 2006 6:17 PM:
My last post about the ApplicationException resulted in some questions along the lines of “so, if not...
# kcwalina said on July 5, 2006 6:19 PM:
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
# theking2 said on October 6, 2006 6:56 PM:
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)
# James Manning » Blog Archive » Python gets right what Java already has, and .NET still hasn’t said on October 27, 2006 9:13 PM:

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

# The Visual Studio Code Analysis Team Blog said on January 31, 2007 12:04 AM:

TypesShouldNotExtendCertainBaseTypes fires on types that derive from ApplicationException and DoNotRaiseReservedExceptionTypes

# knom's developer corner said on May 15, 2007 8:42 AM:

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

# Mike Chaliy's Blog said on May 16, 2007 11:31 AM:

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

# Born 2 Code .NET » Blog Archive » Don’t throw an ApplicationException, not any more! said on May 19, 2007 7:31 AM:

PingBack from http://born2code.net/?p=95

# Tech Blogs by Dominic Zukiewicz said on June 15, 2007 4:15 AM:

Catch ApplicationExceptions? I was wrong!

# Edwin said on June 28, 2007 4:23 AM:

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?

# kcwalina said on June 29, 2007 12:48 PM:

Edwin, you should just inherit from Exception.

# Kalivo.com - ApplicationException vs Exception in .NET said on July 24, 2008 2:43 PM:

PingBack from http://www.kalivo.com/convs/show/1535-applicationexception-vs-exception-in-net

# Jim said on January 15, 2009 11:34 AM:

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

# creating a custom exception | keyongtech said on January 22, 2009 3:23 AM:

PingBack from http://www.keyongtech.com/664993-creating-a-custom-exception

# WangJunwei said on February 11, 2009 10:25 PM:

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

# Marc Jacobi said on April 10, 2009 4:01 PM:

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.

Leave a Comment

(required) 
(optional)
(required) 
Page view tracker