Exceptions

My intention is to use specific exceptions. I didn't know to
what if any extent any exceptions to that guidance was
accepted or advocated.

-----Original Message-----
From: Discussion of development on the .NET platform using
any managed language [mailtoOTNET-CL
RDISCUSS.DEVELOP.COM] On Behalf Of Peter Ritchie
Sent: Sunday, December 03, 2006 16:34
To: DOTNET-CLRDISCUSS.DEVELOP.COM
Subject: Re: [DOTNET-CLR] Exceptions

>Peter, these are all straw men.

I fail to see how they are straw men (based on the weak/sham
argument
definition of straw men).  In the context of a catch-all
these exceptions
do occur and there's really only one thing you can do with
certain
exceptions: try to inform the user and exit; but you can't
do that with a
non top-level catch-all (catch{} or catch(Exception){}) as
presented in
Vince's original post.  But, I fear there was a
miscommunication, please
read on.

>My assertion is that there are cases
>(albeit very rare), where it is acceptable, IMO, to
swallow an exception.
>Even rarer, but still existing, are cases where it is
preferable, IMO, to
>swallow an exception.

In the context of swallow *an* exception, I agree; and
nowhere did I
suggest swallowing *an* exception is a bad thing.  From
Vince's first post
I was in the mind-set of "catch-all" and I may
have misread your response
to Marc as a advocation of catch{}/catch(Exception)--if that
wasn't your
intention, I apologize.  I read Marc's response to refer to
catch-all; but
he does say "don't EVER swallow an exception", I
don't think that's what
he meant by your definition of "swallow". 
Apparently I was not clear (my
first post did not mention catch{}/catch(Exception){} until
the last
paragraph), my assertion has attempted to be swallowing an
indeterminate
set of exceptions is not acceptable--which is the net effect
of catch{}
and catch(Exception){} or trying to catch one of those
poorly designed
abstract-esque Exception-based classes like SystemException
or
ApplicationException.

I would define catching a particular exception and not
informing the user
as one way of "handling" it--AKA
"swallowing".  I wouldn't consider it all
that rare (more rare than rethrowing an exception or
presenting a message
to the user in response to an exception) to handle an
exception in this
way.  There's even a pattern in remotely related to this:
the "TryParse"
pattern.[1]  Although, completely swallowing an exception
would be rare,
usually it's handled to perform certain logic and if that
also fails,
results in informing the user.

But, to swallow an indeterminate set of exceptions by
catching all
exceptions (in light of exceptions that cannot be handled,
exceptions that
by being swallowed would leave the application in an invalid
state, or
exceptions introduced in new version of a library that
didn't exist when
your application was written) is not acceptable.

[1] http://msdn2.microsoft.com/en-us/library/ms229009.aspx

===================================
This list is hosted by DevelopMentorĀ®  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