Re: Re: [BGL] Best way to abort an algorithm from withi n a visitor?

From: David Abrahams (yg-boost-users_at_[hidden])
Date: 2002-09-20 06:26:30

"Jeff Faust" <jeff_at_[hidden]> wrote in message
news:ICEELEJLOALJHNHFDNIDEEJNDFAA.jeff_at_opticalres.com...

> An exceptional case that happens with every run can hardly be called
> exceptional.

One should be wary of ideas that ring too nicely in the ear. Just look, for
example, at how easily taken people in the Physics community (a rigorous
lot!) have been taken by ideas like "self-organized criticality". Exceptions
are a ripe source of such misconceptions, since their name conjures up so
much "meaning"

The rule that "exceptions should only be used for exceptional cases" is
bogus, and it always has been. One problem is that it is based on a highly
subjective term, "exceptional". The other problem is that it doesn't map
well onto the semantics of the actual language construct (stack unwinding).
Exceptions should be used anywhere that their semantics and efficiency are
appropriate to the problem.

I probably shouldn't mention this, but if you insist on keeping your rule
you can stretch it to fit the use-case: in a really large graph, finding the
target node is highly exceptional. You may eventually get there in every
case, but it may only be after examining 100,000 nodes. All of the visits
which don't find the target account for the non-exceptional cases. This is
the one way in which the "rule" is not completely bogus: the implementation
of most EH mechanisms sacrifices the efficiency of the paths where an
exception is thrown to get higher efficiency in the non-throwing code paths.
Thus, it makes sense not to repeatedly throw exceptions from your inner
loops. It would be better to say, "exceptions should be used (comparitively)
rarely".

--
-----------------------------------------------------------
           David Abrahams * Boost Consulting
dave_at_[hidden] * http://www.boost-consulting.com