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/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 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/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 ApplicationException?
Thanks
Russell Mangel
Las Vegas, NV
PS
I wish not, to die of mis-print. 6 6261
Hi Russell,
"Russell Mangel" <ru*****@tymer.net> wrote in message
news:%2****************@TK2MSFTNGP15.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 ApplicationException; 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 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/.../25/96251.aspx
Regards,
Daniel
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,
--
Ignacio Machin,
ignacio.machin AT dot.state.fl.us
Florida Department Of Transportation
"Russell Mangel" <ru*****@tymer.net> wrote in message
news:%2****************@TK2MSFTNGP15.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 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/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 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/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 ApplicationException?
Thanks Russell Mangel Las Vegas, NV
PS I wish not, to die of mis-print.
Hi Ignacio,
"Ignacio Machin ( .NET/ C# MVP )" <ignacio.machin AT dot.state.fl.us> wrote
in message news:%2****************@TK2MSFTNGP15.phx.gbl... 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,
-- Ignacio Machin, ignacio.machin AT dot.state.fl.us Florida Department Of Transportation
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
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/de...classtopic.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/en...sp?frame=false
Cheers,
--
Ignacio Machin,
ignacio.machin AT dot.state.fl.us
Florida Department Of Transportation
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/.../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 )" <ignacio.machin AT dot.state.fl.us> wrote
in message news:us*************@TK2MSFTNGP14.phx.gbl... 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/de...classtopic.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/en...sp?frame=false
Cheers,
-- Ignacio Machin, ignacio.machin AT dot.state.fl.us Florida Department Of Transportation
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,
--
Ignacio Machin,
ignacio.machin AT dot.state.fl.us
Florida Department Of Transportation
"Philip Rieck" <ju**@mckraken.com> wrote in message
news:ea**************@tk2msftngp13.phx.gbl... 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/.../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 )" <ignacio.machin AT dot.state.fl.us>
wrote in message news:us*************@TK2MSFTNGP14.phx.gbl... 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/de...classtopic.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/en...sp?frame=false
Cheers,
-- Ignacio Machin, ignacio.machin AT dot.state.fl.us Florida Department Of Transportation
This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics |
by: Useko Netsumi |
last post by:
in php.ini? Thank
|
by: Fuzzyman |
last post by:
Hello,
To create a classic (old style) class, I write :
class foo:
pass
To do the equivalent as a new style class, I write :
class foo(object):
|
by: CaribSoft |
last post by:
I want to create my own common dialog to use in an application . How do I
show a custom dialog (form) in a class based on the common dialog class?
|
by: moondaddy |
last post by:
Are frame pages really taboo in asp.net and if so, why and what's the down
side of using them? I'm trying to use user controls instead, but it seems
that a lot of things were a lot easier with...
|
by: Ryan Ternier |
last post by:
I just got moved to a project that has an inheritance structure sort of like
this:
MyWebPage.aspx
inherits ---> MyWebPage.ASPX.VB
inherits ----> Utility.VB
inherits -----> DHTMLMenu.vb...
| |
by: Tad Marshall |
last post by:
Hi,
I'm having limited luck getting an ApplicationException to work right in my
code. This is VB.NET, VS 2003, Windows XP SP2, .NET Framework 1.1.
I thought it would be convenient to take...
|
by: toton |
last post by:
Hi,
I want to have a vector like class with some additional functionality
(cosmetic one). So can I inherit a vector class to add the addition
function like,
CorresVector : public...
|
by: bg_ie |
last post by:
Hi,
I have the following Program.cs -
namespace TestFrameworkApplication
{
static class Program
{
/// <summary>
/// The main entry point for the application.
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
| |
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new...
|
by: conductexam |
last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and...
|
by: TSSRALBI |
last post by:
Hello
I'm a network technician in training and I need your help.
I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs.
The...
|
by: adsilva |
last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
|
by: bsmnconsultancy |
last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence...
| |