You are here:

C++/It seems that we can not throw an exception at class level, is there any reason for that?


Sorry about the confusion.

My short example as follows, use snippet2 instead of snippet1.

class myclass {
void myfunction (char param) throw (int) {}

class myclass throw (int) {
void myfunction (char param) {}


Followup To
Question -
Hi, again,

It seems that we can not throw an exception at class level, is there any reason for that?


Answer -
Sorry lzzzz, could you please clarify what you mean by throwing from class level?

A _short_ example would help me then I can try to explain...


I would think there is a good reason...

It is executing code that causes exceptions to occur and code is executed in functions of one sort or another.

What would specifying that a class threw an certain set of exceptions actually mean?

Unless you are operating on instances of that class no code is being executed. And of course not all class members are instance members there are also static members to consider...

So the only thing I can envisage such a declaration meaning would be that all class function members (instance and static probably...) could potentially throw the set of listed exceptions. That is, it is a short hand for applying the exception specifications given for the class to each member function declaration.

In general this would not be true not all member functions will throw at all and of those that did they probably would not all throw the same set of exceptions. The destructor for example should not allow any exceptions to escape as this makes it possible that an object being destroyed while processing one exception throw will in turn throw another exception while still handling that first exception which is a no-no - the runtime gives up and calls terminate in such nested exception cases. See for example.

The only time all member functions might all use the same exception specifications would be for small classes with only a few member functions In these cases the time saved by not typing the exception specifications for each member function is probably not worth the hassle of trying to implement such a feature. And then there is still the question of the destructor which should not really throw anything at all.

I would not get too hung up on exception specifications. Most people try them out then stop using them. As I understand it they cannot be implemented in an efficient way such that there is no cost if the function does not throw an exception. There always has to be runtime support to enforce the specifications they cannot be checked at compile time because the compiler cannot know what all other functions called by the function in question might throw. This of course is not very C++ - one of whose principles is that you only pay for what you use.  


All Answers

Answers by Expert:

Ask Experts


Ralph McArdell


I am a software developer with more than 15 years C++ experience and over 25 years experience developing a wide variety of applications for Windows NT/2000/XP, UNIX, Linux and other platforms. I can help with basic to advanced C++, C (although I do not write just-C much if at all these days so maybe ask in the C section about purely C matters), software development and many platform specific and system development problems.


My career started in the mid 1980s working as a batch process operator for the now defunct Inner London Education Authority, working on Prime mini computers. I then moved into the role of Programmer / Analyst, also on the Primes, then into technical support and finally into the micro computing section, using a variety of 16 and 8 bit machines. Following the demise of the ILEA I worked for a small company, now gone, called Hodos. I worked on a part task train simulator using C and the Intel DVI (Digital Video Interactive) - the hardware based predecessor to Indeo. Other projects included a CGI based train simulator (different goals to the first), and various other projects in C and Visual Basic (er, version 1 that is). When Hodos went into receivership I went freelance and finally managed to start working in C++. I initially had contracts working on train simulators (surprise) and multimedia - I worked on many of the Dorling Kindersley CD-ROM titles and wrote the screensaver games for the Wallace and Gromit Cracking Animator CD. My more recent contracts have been more traditionally IT based, working predominately in C++ on MS Windows NT, 2000. XP, Linux and UN*X. These projects have had wide ranging additional skill sets including system analysis and design, databases and SQL in various guises, C#, client server and remoting, cross porting applications between platforms and various client development processes. I have an interest in the development of the C++ core language and libraries and try to keep up with at least some of the papers on the ISO C++ Standard Committee site at


©2017 All rights reserved.