ApplicationException considered useless

re: ApplicationException considered useless

Haacked — Sat, 24 Jun 2006 01:15:27 GMT

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.

re: ApplicationException considered useless

TAG — Sun, 25 Jun 2006 00:04:15 GMT

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.

re: ApplicationException considered useless

Kalpesh — Sun, 25 Jun 2006 17:00:09 GMT

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

to derive or not to derive from ApplicationException

jokiz's blog — Tue, 27 Jun 2006 16:15:23 GMT

remember the rule to always derive custom exceptions from ApplicationException?&nbsp; so you thought...

re: ApplicationException considered useless

Lance — Tue, 27 Jun 2006 22:03:05 GMT

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?

re: ApplicationException considered useless

TimB — Tue, 04 Jul 2006 03:36:59 GMT

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

Choosing the Right Type of Exception to Throw

Krzysztof Cwalina — Thu, 06 Jul 2006 01:17:18 GMT

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

re: ApplicationException considered useless

kcwalina — Thu, 06 Jul 2006 01:19:08 GMT

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

re: ApplicationException considered useless

theking2 — Sat, 07 Oct 2006 01:56:23 GMT

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

Sat, 28 Oct 2006 04:13:31 GMT

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

FAQ: Why do some sources recommend extending ApplicationException while FxCop does not? [Michael Fanning, David Kean]

The Visual Studio Code Analysis Team Blog — Wed, 31 Jan 2007 08:04:00 GMT

TypesShouldNotExtendCertainBaseTypes fires on types that derive from ApplicationException and DoNotRaiseReservedExceptionTypes

Goodbye ApplicationException!

knom's developer corner — Tue, 15 May 2007 15:42:28 GMT

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

ApplicationException - приходить і уходить....

Mike Chaliy's Blog — Wed, 16 May 2007 18:31:37 GMT

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

Born 2 Code .NET » Blog Archive » Don’t throw an ApplicationException, not any more!

Sat, 19 May 2007 14:31:29 GMT

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

Catch ApplicationExceptions? I was wrong!

Tech Blogs by Dominic Zukiewicz — Fri, 15 Jun 2007 11:15:10 GMT

Catch ApplicationExceptions? I was wrong!

re: ApplicationException considered useless

Edwin — Thu, 28 Jun 2007 11:23:28 GMT

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?

re: ApplicationException considered useless

kcwalina — Fri, 29 Jun 2007 19:48:46 GMT

Edwin, you should just inherit from Exception.

Kalivo.com - ApplicationException vs Exception in .NET

Kalivo.com - ApplicationException vs Exception in .NET — Thu, 24 Jul 2008 21:43:30 GMT

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

re: ApplicationException considered useless

Jim — Thu, 15 Jan 2009 19:34:59 GMT

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

creating a custom exception | keyongtech

creating a custom exception | keyongtech — Thu, 22 Jan 2009 11:23:49 GMT

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

re: ApplicationException considered useless

WangJunwei — Thu, 12 Feb 2009 06:25:55 GMT

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

re: ApplicationException considered useless

Marc Jacobi — Fri, 10 Apr 2009 23:01:45 GMT

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.