This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
C++ throw clause checking in function declarations at compile time
- From: Akos Maroy <darkeye at tyrell dot hu>
- To: gcc at gcc dot gnu dot org
- Date: Sun, 21 Jul 2002 10:04:09 +0200
- Subject: C++ throw clause checking in function declarations at compile time
Hi,
I have a question on C++ exception handling when the exceptions thrown
by functions are declared in the function's throw clause. Take the
following example:
class Exception {
public:
inline Exception( void ) {}
};
class A {
public:
inline void a( void ) throw ( Exception )
{ throw Exception(); }
inline void b( void ) throw ()
{ a(); }
};
When calling A::b(), libstdc++ aborts the program since there is class
thrown from A::b() that is not declared in the throw clause of A::b():
Program received signal SIGABRT, Aborted.
0x420278b1 in kill () from /lib/i686/libc.so.6
(gdb) bt
#0 0x420278b1 in kill () from /lib/i686/libc.so.6
#1 0x420276b8 in raise () from /lib/i686/libc.so.6
#2 0x42028e59 in abort () from /lib/i686/libc.so.6
#3 0x400b6ff7 in __cxxabiv1::__terminate(void (*)()) (
handler=0x42028cc0 <abort>)
at ../../../../libstdc++-v3/libsupc++/eh_terminate.cc:47
#4 0x400b7044 in std::terminate() ()
at ../../../../libstdc++-v3/libsupc++/eh_terminate.cc:57
#5 0x400b7067 in __cxxabiv1::__unexpected(void (*)()) (
handler=0x400b7020 <std::terminate()>)
at ../../../../libstdc++-v3/libsupc++/eh_terminate.cc:63
#6 0x400b6f02 in __cxa_call_unexpected (exc_obj_in=0x80498c0)
at ../../../../libstdc++-v3/libsupc++/eh_personality.cc:456
#7 0x080485b2 in A::b() (this=0xbffff987) at sample.cpp:12
This is all fine. But couldn't gcc check for such issues at compile time
already? As at that time it is already known that A::a() may throw an
Exception class as an exception, but A::b() may not. It is also clear
that A::b() does not handle this exception, thus it will propagate it
upwards. All information is available at that time already. (Java
compilers do this very checking at compile time.)
Maybe gcc could give a warning, or there could be a compilation flag
that would make gcc give a warning in such cases?
Akos