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.
I've heard the argument "Well, how *likely* is it that
that will happen".
The fact is it *could*, and to give something to a customer
where it
*could* silently corrupt their data and manifest itself in a
completely
different area of the application won't impress them. Yes,
an unhandled
exception dialog (or, if you have a top-level catch-all that
presents "An
error occurred and the application must exit, see log for
details.") isn't
impressive, but letting your customer continue with corrupt
data, probably
overwriting their valid data, is worse. At least with an
unhandled
exception dialog their original data is probably intact,
they just have to
repeat some of the steps they performed before the
exception. The fact
remains that if the situation *did* occur with a customer,
the *only*
solution is to not catch all exceptions. But, now you've
pissed of your
customer by corrupting their data--you can't fix that. And,
if you think
it's that *unlikely* those exceptions will be thrown, why
bother catching
it anyway?
I can't think of *any* exception I'd want to
"ignore" and continue
iterating the loop in Vince's original post--but he didn't
give us much
detail. If Vince has a particular exception he wants to
ignore, it would
be much safer to simply use that exception instead of a
catch-all. Also
what's the likelihood of an exception only occurring in one
iteration of
the loop? I would expect once one exception is raised that
exception will
continue to be raised in all subsequent iterations--making
the rest of the
loop *REALLY* slow.
I think it's the other way around, religion is a form of
blind faith.
The "dogma" is people pushing their faith that
catch{} or catch(Exception)
{} doesn't hide bugs and is "safe".
On Sun, 3 Dec 2006 07:39:36 -0700, Steve Johnson
<sjjohnson POBOX.COM>
wrote:
>On 12/3/06, Marc Brooks <idisposablegmail.com> wrote:
>>
>> No. Any unhandled exception should be a fatal
error. You SAY you
>> don't care about the exception, but you don't KNOW
that your caller
>> doesn't...don't EVER swallow an exception anywhere
but top-level
>> (and only there if you know how to tear down and
rebuild state
>> safely).
>>
>
>Oh, come on Marc. I'm amazed at how certain views on
exception handling
are
>becoming like religious dogma. Software engineering is
a lot more art
than
>science, IMO. In my view, there are times when it's
appropriate to
swallow
>an unhandled exception. One example (only one because
I'm lazy and hate
>typing) is inside a finalizer. What happens if your
finalizer throws an
>exception, Marc? And yes, there are also times where *I
don't care* if an
>exception occurs. One example (again, only one because
I'm lazy and hate
>typing) for you. In one application, we download an
updated verification
>list from the internet. We don't want to bother the
user if a copy of the
>list exists locally, unless the local copy is expired
and useless. If
their
>local copy is still valid, we don't allow the
WebException to pass.
>
>The bottom line, IMO, is this: Don't let exception
handling dogma dictate
>the design of your software. I really don't give a damn
if anyone,
>including popular authors and programming gods, likes
how I handle
>exceptions. I do whatever I believe is right in each
particular
situation.
===================================
This list is hosted by DevelopMentorŪ http://www.develop.com
View archives and manage your subscription(s) at http://discuss.develop.com
|