In Transaction environments it is often a good idea to catch all
exceptions to rollback the transaction , id hate to miss a transaction
because I forgot a certain type of exception that may occur such as
Argument out of range ,arithmetic errors etc . In .NET 2.0 this is
handled better with Transaction Scope .
Regards,
Ben
> -----Original Message-----
> From: Unmoderated discussion of advanced .NET topics.
[mailto:ADVANCED-
> [EMAIL PROTECTED] On Behalf Of Peter Ritchie
> Sent: Thursday, 22 September 2005 3:09 AM
> To: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM
> Subject: Re: [ADVANCED-DOTNET] Best way to handle errors in .net
>
> I don't think anyone is interested in a debate on this subject; but,
I'll
> respond to a couple of your questions:
>
> >Second, I would like to say that there are some cases where you might
> >want to catch Exception when trying to open a file. It's pretty much
> >guaranteed that if an Exception of any type is thrown while you're
> >trying to open a file, then the file couldn't be opened.
>
> Why would you make that assumption? File.Open() lists exceptions that
it
> might throw in that version of the assembly; but, those aren't the
only
> exceptions that can be caught by calling File.Open()--one of the many
> methods that File.Open() may call might throw many different other
> exceptions that File.Open() doesn't handle. How can you be sure that
you
> can handle ALL of those exceptions and that one of the methods on the
> stack that led to the calling of your method isn't going to handle a
> particular exception with much better context than you? Not to
mention
> new exceptions added to new versions of the assembly where File.Open
> resides. Sure, a method that calls File.Open is probably in a prime
> context (or should be) to handle FileNotFoundException,
> DirectoryNotFoundException, a subset of IOException exceptions, or
> NotSupportedException; but handling exceptions like
> UnauthorizedAccessException might better be handled further back in
the
> stack where authorization context is known. (I'd argue, in the case
of
> File.Open(), that ArgumentException, ArgumentNullException, and
> ArgumentOutOfRange are fatal and you might as well let them bubble
back
> down the stack as some data validation routine has failed and the
> application invariants have been trashed.)
>
> >Also, is there something wrong with catching Exception and then
showing
> >a message based on its type, with some sort of an "Unknown Error"
> >message being shown if it's a totally unexpected Exception? Maybe
the
> >task of choosing a message for the Exception can be performed by some
> >function.
>
> Again, if something back in the stack is also handling that exception
(of
> which, your function cannot know) you're duplicating functionality and
> probably presenting repetitive messages if you simply rethrow after
> presenting a message. If heard the argument regarding "I know all the
> code"; but, you're still coupling the method calling File.Open() to
any
> method that could be in the stack when File.Open() is called and that
they
> *WON'T* try to catch any exceptions that the method doesn't really
handle.
>
> Anyway, I've reiterated about as much as I need to about the subject
on
> this list. If you want to continue a debate, send me a private
message.
>
> http://www.peterRitchie.com/
>
> ===================================
> This list is hosted by DevelopMentor(r) http://www.develop.com
>
> View archives and manage your subscription(s) at
> http://discuss.develop.com
#####################################################################################
Note:
This message is for the named person's use only. It may contain confidential,
proprietary or legally privileged information. No confidentiality or privilege
is waived or lost by any mistransmission. If you receive this message in error,
please immediately delete it and all copies of it from your system, destroy any
hard copies of it and notify the sender. You must not, directly or indirectly,
use, disclose, distribute, print, or copy any part of this message if you are
not
the intended recipient. THIS COMPANY NAME and any of its subsidiaries each
reserve
the right to monitor all e-mail communications through its networks.
Any views expressed in this message are those of the individual sender, except
where
the message states otherwise and the sender is authorized to state them to be
the
views of any such entity.
Thank You.
#####################################################################################
#####################################################################################
This email has been scanned by MailMarshal, an email content filter.
#####################################################################################
===================================
This list is hosted by DevelopMentor® http://www.develop.com
View archives and manage your subscription(s) at http://discuss.develop.com
