Inheriting from ApplicationException - Taboo? Jeffrey Richter says so...

[Russell Mangel]

Jeffery Richter makes the following statement in two books, the first was
written in 2004, the latter in 2002.
"You should not define new exception classes derived from
ApplicationException; use Exception instead."

..NET Framework Standard Library Annotated Reference, Volume 1: Base Class
Library and Extended Numerics Library (2004)
http://www.aw-bc.com/catalog/academic/product/0,1144,0321154894-DS,00.html

Exception Management Application Block for .NET
http://www.amazon.com/exec/obidos/tg/detail/-/0735614229/103-5946254-8231854?v=glance

I own about 15 C# books, and most of them claim that you should always
inherit from ApplicationException. I am putting some finishing touches on a
class library that I have written in C#, the classes are very similar to the
classes found in System.IO namespace, my library handles very long directory
names and file names, the existing Directory and File classes in FCL can not
do this. I would like to make a good decision on implementation of Exception
Handling for my classes.

Additionally, I also noticed that the "Exception Management Block for .NET"
(April 2002), is inheriting from ApplicationException. I am hesitant to use
it because of Jeffery's comments. He seems to be a well trusted author.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/emab-rm.asp

What is the latest scoop on this? Should I follow Jeffery's advice, or
should I "anger the saints" and inherit from ApplicationException?

Thanks
Russell Mangel
Las Vegas, NV

PS
I wish not, to die of mis-print.

 

[Daniel Pratt]

Hi Russell,

Jeffery Richter makes the following statement in two books, the first was
written in 2004, the latter in 2002.
"You should not define new exception classes derived from
ApplicationException; use Exception instead."

What is the latest scoop on this? Should I follow Jeffery's advice, or
should I "anger the saints" and inherit from ApplicationException?

I'm not sure why Richter is so emphatic with his advice. It is simply the
case that there is no compelling reason to derive from ApplicationException
over Exception. Brad Abrams posted an excerpt from his book that discusses
ApplicationException:

http://blogs.msdn.com/brada/archive/2004/03/25/96251.aspx

Regards,
Daniel

 

[Ignacio Machin \( .NET/ C# MVP \)]

Hi,

AFAIK the recommended way is that you should derive from
ApplicationException, in fact I think that FxCOP has a rule that check this
, also it has a rule saying that you should not catch Exception .

Cheers,

 

[Daniel Pratt]

Hi Ignacio,

Hi,

AFAIK the recommended way is that you should derive from
ApplicationException, in fact I think that FxCOP has a rule that check this
, also it has a rule saying that you should not catch Exception .

Cheers,

Recommended by whom? Not the same folks who brought us
ApplicationException in the first place (the BCL team). They are of the
opinion it was a mistake. Do you think there is a value in deriving from
ApplicationException vs. Exception?

Regards,
Daniel

 

[Ignacio Machin \( .NET/ C# MVP \)]

Hi,

Recommended by whom? Not the same folks who brought us
ApplicationException in the first place (the BCL team). They are of the
opinion it was a mistake. Do you think there is a value in deriving from
ApplicationException vs. Exception?

MS ????
http://msdn.microsoft.com/library/d...frlrfsystemapplicationexceptionclasstopic.asp

except:
ApplicationException is thrown by a user program, not by the common language
runtime. If you are designing an application that needs to create its own
exceptions, derive from the ApplicationException class. ApplicationException
extends Exception, but does not add new functionality. This exception is
provided as means to differentiate between exceptions defined by
applications versus exceptions defined by the system.

As explained ApplicationException function is to differentiate between an
exception generate by the user code and not by the runtime. In a similar way
that SystemException is the base for several exceptions that are generated
by the runtime and considered not fatals.

For further info see:
http://msdn.microsoft.com/library/e...rrorraisinghandlingguidelines.asp?frame=false


Cheers,

 

[Philip Rieck]

Daniel has a point - both Jeff Richter and much of the BCL team have said
that APplicationException was a mistake. See the ".Net Framework Standard
Library Annotated Reference Vol1"

You can see an excerpt of it with the ApplicationException annotations here:
http://blogs.msdn.com/brada/archive/2004/03/25/96251.aspx


This quote is from "KC", or "Krzystof Cwalina (Program Manager ,CLR)"
"Designing exception hierarchies is tricky. Well-designed exception
hierarchies are wide, not very deep, and contain only those exceptions for
which there is a programmatic scenario for catching. We added
ApplicationException thinking it would add value by grouping exceptions
declared outside of the .NET Framework, but there is no scenario for
catching ApplicationException and it only adds unnecessary depth to the
hierarchy."

 

[Ignacio Machin \( .NET/ C# MVP \)]

Hi,

Insteresting read. thanks for the link.

It does have a point, I never catch the ApplicationException, either catch
the particular exception I'm interested or Exception , which I confess that
catch most of the time, almost all of the warnings I get from FxCOP is that,
catching Exception.

Cheers,