Throwing unexpected exceptions

[Urs Thuermann]

In Stroustrup's "The C++ programming language" I read that throwing an
exception that is not declared to be expected in a function causes
std::unexpected() to be called. I tried the difference with the following code

#include <iostream>

#ifdef NO_EXCPT
int foo() throw()
#else
int foo() throw(int)
#endif
{
throw 1;
}

int main()
{
try {
foo();
} catch (...) {
std::cerr << "Exception caught\n";
}
}

But my question is, is there any good reason to intentionally throw
unexpected exceptions? If not, shouldn't the compiler warn about code
that clearly does so, i.e. the above code with NO_EXCPT defined?

urs

 

[Rune Allnor]

In Stroustrup's "The C++ programming language" I read that throwing an
exception that is not declared to be expected in a function causes
std::unexpected() to be called.  I tried the difference with the following code

        #include <iostream>

        #ifdef NO_EXCPT
        int foo() throw()
        #else
        int foo() throw(int)
        #endif
        {
                throw 1;
        }

        int main()
        {
                try {
                        foo();
                } catch (...) {
                        std::cerr << "Exception caught\n";
                }
        }

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?

 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?

Not at all obvious.

Rune

 

[ThosRTanner]

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?


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.

 

[Urs Thuermann]

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?

Not at all obvious.

If I write

void foo() throw() { throw 0; }

the compiler can easily see that the code can actually throw an
exception not listed in the declaration and could warn about it.

In the following example

void bar();
void foo() throw() { bar(); }

the compiler should IMHO assume that bar() might throw any exception,
i.e. foo() might throw any exception, and should warn since the
declaration foo() is probably wrong.

OTOH, if I write

void bar() throw();
void foo() throw() { bar(); }

I wouldn't expect a warning from the compiler (when compiling foo())
since everything seems correct, even if bar() is defined (somewhere
else) to throw some exception. Compiling bar() should then probably
produce a warning.

urs

 

[Balog Pal]

In the following example

void bar();
void foo() throw() { bar(); }

the compiler should IMHO assume that bar() might throw any exception,
i.e. foo() might throw any exception, and should warn since the
declaration foo() is probably wrong.

In wide practice that would be a warning immediately making Alf's
sillywarning list. Only good as noise.

 

[Dombo]

Op 16-Jun-11 10:50, Urs Thuermann schreef:

In Stroustrup's "The C++ programming language" I read that throwing an
exception that is not declared to be expected in a function causes
std::unexpected() to be called. I tried the difference with the following code

#include<iostream>

#ifdef NO_EXCPT
int foo() throw()
#else
int foo() throw(int)
#endif
{
throw 1;
}

int main()
{
try {
foo();
} catch (...) {
std::cerr<< "Exception caught\n";
}
}

But my question is, is there any good reason to intentionally throw
unexpected exceptions? If not, shouldn't the compiler warn about code
that clearly does so, i.e. the above code with NO_EXCPT defined?

If you consider using exception specifications in your code I recommend
you read this article first: http://www.gotw.ca/publications/mill22.htm