Re: Why do some code bases don't use exceptions?
On Nov 25, 7:26 pm, Stuart Golodetz
<sgolod...@NdOiSaPlA.pMiPpLeExA.ScEom> wrote:
<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).
I guess you could always go down the Java-like route of
introducing a checked_exception base class for exceptions
which can be checked in exception specifications and assuming
that where legacy code does throw, it throws only unchecked
exceptions. Not sure this would make things any easier though?
It seems to combine the disadvantages of both. In practice,
most of Java's checked exceptions are things that logically
should be a return code: things that usually have to be handled
locally, by the calling function. At present, C++ does it
better (although IMHO, compile time checking would be better
still, if it weren't for the problem of legacy code): the most
useful guarantee (perhaps the only useful guarantee) is that a
function doesn't exit via an exception, ever. You can't express
this guarantee in Java.
>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.)
Just to clarify: do you think it doesn't need a try block, or
that that's not a problem? (FWIW, my current answers to those
would be that I think it does need a try block, but that I
don't think that's a major problem - but I'm open to
thoughts.)
I don't think that it would be a problem requiring the try
block. I'm really in favor of static checking. But I've
definitely heard the above argument. (Note that some early
implementations of exceptions and try blocks had some runtime
costs, which might not be acceptable in such a function. I
don't think that this would be an issue with most modern
compilers, however.)
--
James Kanze