"Jeff Faust"
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@boost-consulting.com * http://www.boost-consulting.com