|
Boost Users : |
From: Jeff Faust (jeff_at_[hidden])
Date: 2002-09-19 13:04:12
> From: Peter Dimov [mailto:pdimov_at_[hidden]]
> >
> > 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
Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net