Peter, please accept my apology for missing the context conveyed by the
capital letter E. I completely agree with you after you pointed this out.
If Mark would like another revision, I would suggest that we could make the
point even clearer by stating that:
Developers should never catch non-CLS compliant exceptions
(e.g. a catch statement with no exception type), or a CLR base exception
(System.Exception, System.SystemException, or System.ApplicationException).
While the last two base class exception types (which inherit from
System.Exception) have been made mostly irrelevant because developers inside
and outside of Microsoft ignored their intended purposes, catching them is
still considered nearly as bad as catching System.Exception.
The 2.0 framework will wrap and re-throw non-CLS exceptions inside of a CLS
exception so that all exceptions can be caught, not just those that are CLS
compliant. Information on this new feature and another version of Mark's
advice on exceptions can be found at:
http://msdn2.microsoft.com/en-us/library/ms135515
Cheers!
Paul Mehner
South Sound .NET User Group
http://www.ssdotnet.org
-----Original Message-----
From: Unmoderated discussion of advanced .NET topics.
[mailto:[EMAIL PROTECTED] On Behalf Of Peter Ritchie
Sent: Friday, September 16, 2005 8:44 PM
To: [email protected]
Subject: Re: [ADVANCED-DOTNET] Best way to handle errors in .net
Paul, the capital E on Exception didn't make it clear. I wasn't
advocating that exceptions should never be caught (that's wrong on many
levels) I was talking about the class "Exception". (with clarification
from Mark) "Exception" should never be caught without rethrow, except in a
top-level handler. This is based upon "don't catch exceptions you don't
know how to handle", the "Exception" class cannot provide enough
information to be handled (except at a top-level handler where you just
log the exception and exit).
http://www.peterRitchie.com/
On Fri, 16 Sep 2005 13:31:11 -0700, Paul Mehner <[EMAIL PROTECTED]> wrote:
>I agree with Peter Ritchie that Mark Brooks' documentation on exceptions
is
>"exceptionally" good. There are times though, Peter, when catching an
>exception _is_ the right thing to do (see Mark's 2nd part of #1) and
>therefore it should not be re-thrown. For example, if I caught a
>System.IO.FileNotFoundException and then I prompted the user to show me
>where the file was located, this would be a case where catching an
exception
>without re-throwing is the correct thing to do. You must therefore re-word
>your suggestion to be "always re-throw exceptions that you catch and don't
>properly handle" -- but because that statement would violate the primary
>rules for catching exceptions, I am forced to respectfully disagree with
the
>clarification.
>
>Cheers!
>
>--Paul
>
>
>-----Original Message-----
>From: Unmoderated discussion of advanced .NET topics.
>[mailto:[EMAIL PROTECTED] On Behalf Of Peter Ritchie
>Sent: Friday, September 16, 2005 11:34 AM
>To: [email protected]
>Subject: Re: [ADVANCED-DOTNET] Best way to handle errors in .net
>
>Excellent exception practices. I would only clarify that Exception should
>never be caught without a rethrow.
>
>http://www.peterRitchie.com/
>
>Mark Brooks wrote:
>
>First as regards exceptions themselves:
>
>1. Do NOT catch exceptions you don't know how to handle - this means
>correct for the problem or do some unwind work. If you _KNOW_ what to
>do when an Exception happens, catch. If not, DON'T.
>
>2. Do NOT catch exceptions to merely translate the to another type of
>exception (even if you do set the InnerException property). If you
>don't have something to add, don't catch. This is wrong:
> catch (Exception ex)
> {
> // do something interesting (see 1)
> throw new MyCoolException("nothing of value here", ex);
> }
>
>3. Do NOT catch an exception then throw it again, rather do a
>"rethrow". This is wrong:
> catch (Exception ex)
> {
> // do something interesting (see 1)
> throw ex; // StackTrace now loses everything below this level
> }
>
>Rather do this:
> catch (Exception ex)
> {
> // do something interesting (see 1)
> throw; // notice there's no ex! The original StackTrace is left
>intact.
> }
>
>4. Do NOT derive all of your exceptions from ApplicationException (or
>some other base level exception of your creation), as you are not
>adding value by doing so. If you want to standardize your exception
>creation, write builder methods to throw specific exceptions in
>regular "forms".
>
>5. If you do have contextual information you can add to an exceptionm,
>DO SO. Use the Exception.Data collection, that's what it is there
>for! You can add the values of interesting parameters to you methods.
> This is especially useful in the context of a database layer or other
>low-level library. You can squirrel-away the SQL and all the
>parameters. Only do this if you think that these details will be
>useful for post-mortem diagnosis. If the information you log is
>transitory it will NOT help tracking down errors from logs. This is
>(mostly) good:
> catch (Exception ex)
> {
> ex.Data.Add("SQL", command.Text);
> ex.Data.Add("key", myKey);
> // or enumerate command Parameters collection
> throw; // (see #3)
> }
>
>6. If you add things to the Exception.Data collection, make sure that
>you don't conflict with what is already there as this is a HashTable.
>I use the catching-class's name to scope the values. This is much
>better than #5:
> catch (Exception ex)
> {
> ex.Data.Add(typeof(MyClass).ToString() + ".MyMethod.SQL",
>command.Text);
> throw; // (see #3)
> }
>
>7. If you are catching exceptions to do some undo-work (like rolling
>back transactions, closing handles, etc.) Strongly consider creating a
>_very small_ wrapper for that resource and implementing IDisposable on
>it. Then you can have a "using" clause to hide the try { } finally {
>} block.
===================================
This list is hosted by DevelopMentor(r) http://www.develop.com
View archives and manage your subscription(s) at http://discuss.develop.com
===================================
This list is hosted by DevelopMentor® http://www.develop.com
View archives and manage your subscription(s) at http://discuss.develop.com
