Re: Throwing unexpected exceptions
On Jun 16, 11:13 am, Rune Allnor <all...@tele.ntnu.no> wrote:
On Jun 16, 10:50 am, Urs Thuermann <u...@isnogud.escape.de> wrote:
But my question is, is there any good reason to intentionally throw
unexpected exceptions?
How would you, the programmer, know what exceptions
your function might throw? How do you define 'throw'?
Consider the function
void f()
{
std::vector<double> v;
v.reserve(1e80); // Not enough memory
}
Clearly, few systems have enough memory available to
accomodate the requested amount of memory, so the
call v.reserve() will throw a bad_alloc exception.
But which class / function 'threw'? Your function?
std::vector<T>::reserve() ?
If not, shouldn't the compiler warn about code
that clearly does so, i.e. the above code with NO_EXCPT defined?
How would the compiler be able to analyze all the
internal code to deduce which exceptions might and
which might not be thrown? One might easily imagine
a situation where your function calls a pre-compiled
library, that might throw. How would the compiler
be able to analyze that kind of situation?
It's trivial for the compiler to tell that a function might throw, and
warn, because the signature of each function tells you whether it
might throw.
pc-lint does this, and very useful it is if you don't want your
program to terminate because someone threw an exception they weren't
allowed to
It doesn't need to examine the code, in the same way it doesn't need
to examine the possible code paths to determine to determine that
this:
void func(char * s);
myfunc(char const *s) { func(s) };
is invalid, even if func never updates s. Yet no one complains about
this behaviour.