Inheriting from ApplicationExce ption - 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
ApplicationExce ption; 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/academi...894-DS,00.html

Exception Management Application Block for .NET
http://www.amazon.com/exec/obidos/tg...31854?v=glance

I own about 15 C# books, and most of them claim that you should always
inherit from ApplicationExce ption. 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 ApplicationExce ption. I am hesitant to use
it because of Jeffery's comments. He seems to be a well trusted author.
http://msdn.microsoft.com/library/de...ml/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 ApplicationExce ption?

Thanks
Russell Mangel
Las Vegas, NV

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

[Daniel Pratt]

Hi Russell,

"Russell Mangel" <ru*****@tymer. net> wrote in message
news:%2******** ********@TK2MSF TNGP15.phx.gbl. ..

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
ApplicationExce ption; use Exception instead." <snip> What is the latest scoop on this? Should I follow Jeffery's advice, or
should I "anger the saints" and inherit from ApplicationExce ption?

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 ApplicationExce ption
over Exception. Brad Abrams posted an excerpt from his book that discusses
ApplicationExce ption:

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

Regards,
Daniel

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

Hi,

AFAIK the recommended way is that you should derive from
ApplicationExce ption, 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,

--
Ignacio Machin,
ignacio.machin AT dot.state.fl.us
Florida Department Of Transportation

"Russell Mangel" <ru*****@tymer. net> wrote in message
news:%2******** ********@TK2MSF TNGP15.phx.gbl. ..

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
ApplicationExce ption; 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/academi...894-DS,00.html

Exception Management Application Block for .NET
http://www.amazon.com/exec/obidos/tg...31854?v=glance
I own about 15 C# books, and most of them claim that you should always
inherit from ApplicationExce ption. 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 ApplicationExce ption. I am hesitant to use it because of Jeffery's comments. He seems to be a well trusted author.
http://msdn.microsoft.com/library/de...ml/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 ApplicationExce ption?

Thanks
Russell Mangel
Las Vegas, NV

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

[Daniel Pratt]

Hi Ignacio,

"Ignacio Machin ( .NET/ C# MVP )" <ignacio.mach in AT dot.state.fl.us > wrote
in message news:%2******** ********@TK2MSF TNGP15.phx.gbl. ..

Hi,

AFAIK the recommended way is that you should derive from
ApplicationExce ption, 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,

--
Ignacio Machin,
ignacio.machin AT dot.state.fl.us
Florida Department Of Transportation

Recommended by whom? Not the same folks who brought us
ApplicationExce ption 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
ApplicationExce ption vs. Exception?

Regards,
Daniel

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

Hi,

Recommended by whom? Not the same folks who brought us
ApplicationExce ption 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
ApplicationExce ption vs. Exception?

MS ????
http://msdn.microsoft.com/library/de...classtopic.asp

except:
ApplicationExce ption 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 ApplicationExce ption class. ApplicationExce ption
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 ApplicationExce ption 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/en...sp?frame=false
Cheers,

--
Ignacio Machin,
ignacio.machin AT dot.state.fl.us
Florida Department Of Transportation

[Philip Rieck]

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

You can see an excerpt of it with the ApplicationExce ption annotations here:
http://blogs.msdn.com/brada/archive/.../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
ApplicationExce ption thinking it would add value by grouping exceptions
declared outside of the .NET Framework, but there is no scenario for
catching ApplicationExce ption and it only adds unnecessary depth to the
hierarchy."
"Ignacio Machin ( .NET/ C# MVP )" <ignacio.mach in AT dot.state.fl.us > wrote
in message news:us******** *****@TK2MSFTNG P14.phx.gbl...

Hi,

Recommended by whom? Not the same folks who brought us
ApplicationExce ption 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
ApplicationExce ption vs. Exception?

MS ????
http://msdn.microsoft.com/library/de...classtopic.asp

except:
ApplicationExce ption 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 ApplicationExce ption class.
ApplicationExce ption
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 ApplicationExce ption 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/en...sp?frame=false
Cheers,

--
Ignacio Machin,
ignacio.machin AT dot.state.fl.us
Florida Department Of Transportation

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

Hi,

Insteresting read. thanks for the link.

It does have a point, I never catch the ApplicationExce ption, 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,

--
Ignacio Machin,
ignacio.machin AT dot.state.fl.us
Florida Department Of Transportation

"Philip Rieck" <ju**@mckraken. com> wrote in message
news:ea******** ******@tk2msftn gp13.phx.gbl...

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

You can see an excerpt of it with the ApplicationExce ption annotations here: http://blogs.msdn.com/brada/archive/.../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
ApplicationExce ption thinking it would add value by grouping exceptions
declared outside of the .NET Framework, but there is no scenario for
catching ApplicationExce ption and it only adds unnecessary depth to the
hierarchy."
"Ignacio Machin ( .NET/ C# MVP )" <ignacio.mach in AT dot.state.fl.us > wrote in message news:us******** *****@TK2MSFTNG P14.phx.gbl...

Hi,

Recommended by whom? Not the same folks who brought us
ApplicationExce ption 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 ApplicationExce ption vs. Exception?

MS ????
http://msdn.microsoft.com/library/de...classtopic.asp
except:
ApplicationExce ption 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 ApplicationExce ption class.
ApplicationExce ption
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 ApplicationExce ption 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/en...sp?frame=false

Cheers,

--
Ignacio Machin,
ignacio.machin AT dot.state.fl.us
Florida Department Of Transportation