Dear Frinds,
In the context of handling errors, I wud like to take our discussion a bit
ahead.
I would like to know the following things:
1. What information we should store in the log files.
2. I am having a XML file created at the client side. The
application is based on ASP.Net. I would like to know the best ways to
receive the error information. I mean to say what are the ways to get the
information from client side. For eg., I should ask my client my client to
mail that xml file or should I write a function that notifies me through
smtp that an error has occurred or should I write some function to get the
xml file at periodic intervals, so that I can fix up the problem and give
him a updated dll file.
Thanks,
Aggarwal.
-----Original Message-----
From: Unmoderated discussion of advanced .NET topics.
[mailto:[EMAIL PROTECTED] On Behalf Of Peter Ritchie
Sent: Saturday, September 17, 2005 10:16 PM
To: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM
Subject: Re: [ADVANCED-DOTNET] Best way to handle errors in .net
Paul, I agree, clarifying that CLR base exception types (Exception,
SystemException, ApplicationException) should not be caught without rethrow
is an excelling suggestion.
http://www.peterRitchie.com/
On Sat, 17 Sep 2005 09:54:35 -0700, Paul Mehner <[EMAIL PROTECTED]> wrote:
>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: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM
>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: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM
>>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 DevelopMentorR 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
