RE: [boost] Re: Threads by Jeremy and Monitors in one?

From: Reid Sweatman (borderland_at_[hidden])
Date: 2000-08-11 18:08:18

> -----Original Message-----
> From: David Abrahams [mailto:abrahams_at_[hidden]]
> Sent: Friday, August 11, 2000 12:08 PM
> To: boost_at_[hidden]
> Subject: Re: [boost] Re: Threads by Jeremy and Monitors in one?

> I recently had a discussion with a junior colleague about when to use
> exceptions vs. when to use assert, and he concluded the conversation by
> observing, "So, exceptions are for errors we *expect* to happen". In
> context, his observation was perfectly accurate. We use exceptions for
> things like running out of memory, which (on our platform) is a possible
> scenario from which we need to recover. We use assertions to catch
> programming errors (violations of preconditions), i.e. conditions we don't
> expect to occur once our code is debugged and shipped.
>
> Many other experienced people come to the opposite conclusion about
> "expectedness". The problem is that "expectedness" is a poorly-defined,
> qualitative term.
>
> -Dave
>
> P.S. In this case, I don't even think the timeout condition neccessarily
> represents an error, though I'm not religious about exceptions being used
> only for error conditions. Of course, "errorness" may be another
> qualitative
> term.

I think you just put me closer to understanding the problem.  As I had
understood it, exceptions were used in cases where the class contract was
violated.  However, preconditions are part of the contract, and, as you say,
assertions are the way to go there.  But then, that raises the whole issue
of whether the class contract as a whole should be enforced by invariant
testing; maybe only throw if the invariant test fails.  Seems to me that
what has happened in the spec is that several differing mechanisms have been
created to handle problem domains that have a lot of spill-over, making it
unclear which to use for any given purpose.  If that's actually the case,
then any attempt to sort out exactly what you can legitimately use an
exception for is doomed from the get-go.  Still you need some kind of
convention, or you're certainly going to get errors in exception usage based
on different perceptions of their purpose, especially on large projects.
I'm beginning to understand why some people here aren't too gung ho on
exceptions to begin with.

One last try:  it seems to me that the phrase "errors we *expect* to happen"
is also ambiguous.  Your example of running out of memory isn't necessarily
an "error," since it isn't necessarily fatal (for instance, a local catch
block could free memory and retry the allocation; that doesn't seem like an
error, unless it ends up being unrecoverable).  However, another point in
favor of your interpretation is the existence of unexpected(), which by its
very semantics supports you.  Think better sacrifice something bigger this
time; but hut getting very bloody <g>.

Reid Sweatman