Exceptions

On 12/3/06, Peter Ritchie
<dotnetclr.discuss.develop.competerritchie.com>
wrote:
>
> It amazes me that people still present arguments like
this.  What about
> OutOfMemoryException, or if
DoSomethingThatMightErrorButIDontCareIfItDoes
> attempts to update the database and the database is
remote and the network
> or the server has gone down or timed out?  What is a
database driver
> update introduces an AccessViolationException?  What
about
> NullReferenceException?  What if
> DoSomethingThatMightErrorButIDontCareIfItDoes uses data
from the database
> and doesn't check for zero when using that data as a
denominator, i.e. the
> ArithmeticException?  Etc. etc. etc.  Does continuing
in a loop make sense
> in those situation.  Of course not.
>

Peter, these are all straw men.  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.  By pointing out all these scary
scenarios where it
obviously wouldn't be a good idea to swallow exceptions,
you've not even
addressed the issue at hand, let alone succeed at solving
anything.

--
Steve Johnson

===================================
This list is hosted by DevelopMentorŪ  http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com

One classic case I have found is in remoting having multiple
subscribers
to an event. In my code, I loop through each delegate and
raise the
event - if it errors, what on earth can I do? I simply
cannot let the
app fail - there might be valid subscribers still listening
and still
waiting for that event. If the client crashed and they
re-connected,
then that original delegate is now dead and should be
ignored/removed.
If the network dropped, is it likely to re-connect
automatically?
(Serious question - not rhetorical). In this case, if the
event fails to
raise, then there is extremely little I can do about it, and
it's not
unexpected either - I'd wager that not many programmers
detach all
events before an object goes out of scope.

Dino

-----Original Message-----
From: Discussion of development on the .NET platform using
any managed
language [mailtoOTNET-CL
RDISCUSS.DEVELOP.COM] On Behalf Of Steve
Johnson
Sent: Monday, 4 December 2006 09:11
To: DOTNET-CLRDISCUSS.DEVELOP.COM
Subject: Re: [DOTNET-CLR] Exceptions

On 12/3/06, Peter Ritchie
<dotnetclr.discuss.develop.competerritchie.com>
wrote:
>
> It amazes me that people still present arguments like
this.  What 
> about OutOfMemoryException, or if 
> DoSomethingThatMightErrorButIDontCareIfItDoes
> attempts to update the database and the database is
remote and the 
> network or the server has gone down or timed out?  What
is a database 
> driver update introduces an AccessViolationException? 
What about 
> NullReferenceException?  What if 
> DoSomethingThatMightErrorButIDontCareIfItDoes uses data
from the 
> database and doesn't check for zero when using that
data as a 
> denominator, i.e. the ArithmeticException?  Etc. etc.
etc.  Does 
> continuing in a loop make sense in those situation.  Of
course not.
>

Peter, these are all straw men.  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.  By pointing out all these scary
scenarios
where it obviously wouldn't be a good idea to swallow
exceptions, you've
not even addressed the issue at hand, let alone succeed at
solving
anything.

--
Steve Johnson

===================================
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