Exceptions

> If I have a foreach loop that's doing a
non-mission-critical task but yet
> want to ensure that the operation is attempted for each
member of a
> collection, is it "ok" to have a empty Catch?

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, nor do you know if that exception left things in an
unstable
state. When will you find that out?  Before or after you've
corrupted
the poor user's data permanently?  Please, for the love of
all that is
holy and just, don't EVER swallow an exception anywhere but
top-level
(and only there if you know how to tear down and rebuild
state
safely).

That said, what you seem to want is "broadcast"
symantics. Basically
allowing everyone a crack at the message and letting them
toss thier
cookies if desired.  I would do that by wrapping the caught
exceptions
in a "lots of things failed" Exception class that
exposes them like
(but not using) InnerException. Then your inner loop catch
can just
.Add them to the collection and after the loop executes you
can toss
the Exception if the collection is empty...

Not that I would do it, because I strongly believe in
fast-fail... but:

CatchAllException holder = new CatchAllException();

foreach(DataRow row in ds.Tables[0].Rows)
{
   try {
      DoSomethingThatMightErrorButIDontCareIfItDoes(row);
   }
   catch (Exception ex) {
      holder.Exceptions.Add(ex);
   }
}

if (holder.Exceptions.Count > 0) {
   throw holder;
}

--
"Statistics do not apply to anyone, however they do
apply to everyone."
Marc C. Brooks
http://musingmarc.blog
spot.com

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

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

Thanks for your help Marc. I know I probably should have
wrote a little bit more about how I understand that
generally this way of handling errors is ill advised but as
much as I want to care about the errors in some areas of my
program, I always run into the truth.. those errors donā€™t
matter and the user shouldn't be bothered with them.  So
that means not letting the program crash in order to follow
a design principle to its extreme. Surely there's some
corners in every app where this is the case, isn't it? (I'm
sincerely asking... not being rhetorical)


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

> If I have a foreach loop that's doing a
non-mission-critical task but yet
> want to ensure that the operation is attempted for each
member of a
> collection, is it "ok" to have a empty Catch?

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, nor do you know if that exception left things in an
unstable
state. When will you find that out?  Before or after you've
corrupted
the poor user's data permanently?  Please, for the love of
all that is
holy and just, don't EVER swallow an exception anywhere but
top-level
(and only there if you know how to tear down and rebuild
state
safely).

That said, what you seem to want is "broadcast"
symantics. Basically
allowing everyone a crack at the message and letting them
toss thier
cookies if desired.  I would do that by wrapping the caught
exceptions
in a "lots of things failed" Exception class that
exposes them like
(but not using) InnerException. Then your inner loop catch
can just
.Add them to the collection and after the loop executes you
can toss
the Exception if the collection is empty...

Not that I would do it, because I strongly believe in
fast-fail... but:

CatchAllException holder = new CatchAllException();

foreach(DataRow row in ds.Tables[0].Rows)
{
   try {
      DoSomethingThatMightErrorButIDontCareIfItDoes(row);
   }
   catch (Exception ex) {
      holder.Exceptions.Add(ex);
   }
}

if (holder.Exceptions.Count > 0) {
   throw holder;
}

--
"Statistics do not apply to anyone, however they do
apply to everyone."
Marc C. Brooks
http://musingmarc.blog
spot.com

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

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.

--
Steve Johnson

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

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

> Oh, come on Marc.

Where are we going?  A religious argument?

> I'm amazed at how certain views on exception handling
are
> becoming like religious dogma

Yep, thought so...

> Software engineering is a lot more art than science,
IMO.

In that we argree completely... unfortunately most people
are
approaching it like art (ooo, look how shiny my cool
animations are...
ignore the smoking hole where you data used to be).

> In my view, there are times when it's appropriate to
swallow
> an unhandled exception.

We disagree. I'm okay with that.

> One example (only one because I'm lazy and hate
> typing) is inside a finalizer.

You are not supposed to leak (or better yet, not throw)
during a
finalizer, so yes, you need to catch (or better yet, not
cause to be
thrown) exceptions. Personally I try to avoid finalizers as
much as
possible. But I will NOT catch an exception I didn't
anticipate and
know how to handle, because doing so WILL allow futher
corruption to
occur. It's much better to let the app crash and be
recycled.

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

I would classify this as HANDLING an exception, not
swallowing it. You
know exactly what kinds of exceptions _should be ignored_
and thus you
KNOW how to handle them in this case. Catching any other
exceptions
than the well-defined ones you KNOW you are handling is a
mistake.

> The bottom line, IMO, is this:  Don't let exception
handling dogma dictate
> the design of your software.

Correct, exception handling should be EXCEPTIONAL. You
should only
deal with those things you know how to deal with. Anything
else is
arrogant.

> I really don't give a damn if anyone, including popular
authors
> and programming gods, likes how I handle exceptions.

Nor do I...

>  I do whatever I believe is right in each particular
situation.

I just hope the SQL Server developers are less cavalier
about what
they swallow (not handle) than you seem to be calling for...

--
"Statistics do not apply to anyone, however they do
apply to everyone."
Marc C. Brooks
http://musingmarc.blog
spot.com

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

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

On 12/3/06, Marc Brooks <idisposablegmail.com> wrote:
>
> I just hope the SQL Server developers are less cavalier
about what
> they swallow (not handle) than you seem to be calling
for...
>

You and Peter both seem to be operating under the assumption
that asserting
that there are some rare cases where it's permissible to
swallow an
exception means that I advocate a generally haphazard
exception handling
strategy.  Exception handling strategy is a critical part of
engineering any
application, from the overall application strategy, right
down to designing
individual methods and blocks to handle exceptions
appropriately.  To assert
that I advocate a cavalier attitude in this area could not
be more off
target.

--
Steve Johnson

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

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

You stated exactly my sentiments.

Though unlike the fight I found myself in last week, I
wasn't offended by Peter's emails, knowing that he did have
the best intention in mind.

-----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: Sunday, December 03, 2006 14:19
To: DOTNET-CLRDISCUSS.DEVELOP.COM
Subject: Re: [DOTNET-CLR] Exceptions

On 12/3/06, Marc Brooks <idisposablegmail.com> wrote:
>
> I just hope the SQL Server developers are less cavalier
about what
> they swallow (not handle) than you seem to be calling
for...
>

You and Peter both seem to be operating under the assumption
that asserting
that there are some rare cases where it's permissible to
swallow an
exception means that I advocate a generally haphazard
exception handling
strategy.  Exception handling strategy is a critical part of
engineering any
application, from the overall application strategy, right
down to designing
individual methods and blocks to handle exceptions
appropriately.  To assert
that I advocate a cavalier attitude in this area could not
be more off
target.

--
Steve Johnson

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