Re: Why do some code bases don't use exceptions?
On Nov 25, 3:07 pm, Stuart Golodetz
<sgolod...@NdOiSaPlA.pMiPpLeExA.ScEom> wrote:
James Kanze wrote:
On Nov 21, 2:57 am, Paavo Helde <myfirstn...@osa.pri.ee> wrote:
James Kanze <james.ka...@gmail.com> wrote in
news:f37f1e13-cdcc-4144-
b526-364f2bcf6...@s31g2000yqs.googlegroups.com:
On Nov 17, 8:43 pm, Paavo Helde <myfirstn...@osa.pri.ee> wrote:
krel <k...@example.invalid> wrote innews:hduq8e$4f9$1@news.eternal-
september.org:
and badly designed feature".
In C++, there are surprisingly few "broken and badly
designed features".
That's very arguable. The question isn't so much whether
C++ does it right; it's usually a question of other
languages not supporting it at all.
Non-empty exception specifications are one example,
Broken and badly designed, or simply a more or less good
solution without a problem?
I would say broken and badly designed as they solve even
the perceived problem inadequately (app termination is not
an adequate solution imo, and catch(...) is better than
using a global unexpected handler).
What is the perceived problem? And why is aborting (as a
default behavior) a bad solution? Violating an exception
specification is a contract violation, so aborting *is*
about the only appropriate default behavior. The question
is: what problem is solved by supporting contracts in which
a function is allowed to throw a limited set of exceptions
(as opposed to no exception).
<snip>
I don't really understand why the violation check's being done
at runtime rather than compile time (the way checked
exceptions in Java work) - the "what should happen if an
unexpected exception is thrown at runtime?" question is fair
enough, but why does it get to that point in the first place?
Is it difficult/impossible to do the check at compile time in
C++? Or is the issue that it would break a lot of old code
where the functions don't have exception specifications?
There are (I think) several reasons. One obvious one is that
that if you don't specify anything, the compiler will assume
that a function can throw anything, so you'd end up needing a
lot of otherwise useless try blocks with legacy code (since the
code doesn't declare that it can't throw, but it doesn't in fact
ever throw, and you know that). The other is the IMHO misguided
theory that it would require the programmer to provide
additional runtime checks. If, for example, you have a sqrt
function with throws if passed a negative value, and you write
something like:
double
checked_sqrt(double in) throw()
{
return in < 0.0 ? 0.0 : sqrt(in);
}
you'd need a try block to tell the compiler that you're not
going to allow any exceptions to escape. (As I said, I don't
actually agree with this reasoning. But it's a reason I've
heard cited.)
--
James Kanze