Re: Exceptions as return values
- From: "Jon Skeet [C# MVP]" <skeet@xxxxxxxxx>
- Date: 10 Jan 2006 07:37:44 -0800
Alan Pretre wrote:
> Being nitpicky...
>
> User exceptions should derive from System.ApplicationException, not
> System.Exception. See the Remarks section here in MSDN:
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfsystemapplicationexceptionclasstopic.asp
>
> To wit:
> "This exception is provided as means to differentiate between exceptions
> defined by applications versus exceptions defined by the system."
However, look at this:
http://blogs.msdn.com/brada/archive/2004/03/25/96251.aspx
quoting the .NET Framework Standard Library Annotated Reference Vol 1:
<quote>
KC - 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.
JR - You should not define new exception classes derived from
Application-
Exception; use Exception instead. In addition, you should not write
code that
catches ApplicationException.
</quote>
Jon
.
- Follow-Ups:
- Re: Exceptions as return values
- From: Alan Pretre
- Re: Exceptions as return values
- References:
- Exceptions as return values
- From: dcassar
- Re: Exceptions as return values
- From: Nicholas Paldino [.NET/C# MVP]
- Re: Exceptions as return values
- From: David Levine
- Re: Exceptions as return values
- From: Alan Pretre
- Exceptions as return values
- Prev by Date: Re: Question about Databinding - binding controls to members of my business object.
- Next by Date: Re: Hint about tabs
- Previous by thread: Re: Exceptions as return values
- Next by thread: Re: Exceptions as return values
- Index(es):
Relevant Pages
|
