From: Peter Dimov [mailto:pdimov@mmltd.net]
Something is more maintainable if it is more understood.
Even if it's made more complicated by littering the algorithms with completely redundant return value checks?
In this case, yes, and I'd hardly call it redundant. It sounds like a useful mechanism to be able to stop the algorithm from processing once a goal is achieved. There is no such mechanism built in. Exceptions can be used to achieve this, but it's not how exceptions are commonly used, and not how they are commonly understood.
Exceptions are meant for exceptional cases. [...]
Define "exceptional cases". How exceptions work is well defined, and therefore can be understood, whereas an "exceptional case" is always assumed to be intuitively obvious.
Something unexpected. The example give by the original poster is describing a normal execution. This is not unexpected. It's strange to think that what occurs in the catch block is not error recover/reporting, but normal and expected execution. This is not an obvious usage of exceptions.
Staying within expectations may mean sacrificing performance. There is often a trade-off between performance and maintainability. The pros and cons should be weighed and a choice made.
Performance? It's about code clarity, not performance.
I was looking at the choice between using exceptions and letting the algorithm run to completion. I was not thinking about modifying the algorithm. My oversight. Of course everything I say is by today's standards and those standards may change. But since tomorrow's standards are unknown, it's a bad argument, and an argument that could be used to support anything. Jeff Faust