> The above works on code::blocks, which uses some form of GCC, and > looks OK to me. > Of course this only works for exactly one exception type. > You'd have to wait for C++0X variadic templates (and hope you can > throw them) if you need zero or more than one. > It's also very verbose, a little cryptic, and nested templates could > make variadic versions horrifically long. > However it's a start. > All these are reasons why such a feature will not be used. Trying to write code with C++ exception specifications has a LOT of problems in addition to things you mentioned above i can think of a few:
* It is VERY difficult to get correct (compounded across platforms and versions of libraries/compilers, or with different compile time options etc that may cause different exceptions to be thrown) * It has the great feature, where if you do get it wrong it likes to call that lovely terminate function (Dripping with sarcasm...) * Maintaining code with such specifications is cumbersome and a LOT of work (I tried it). * A lot of difficulties arise in the presence of templates in determining what exceptions may be thrown (And solutions described are cumbersome) * There is no compile time assertion of compliance (This is solved by EDoc++, but may also be solved in part by the warning feature being proposed). This is where Java differs, it has a compile time compliance that "non-runtime" exceptions are specified/handled. But as i understand it no runtime assertion (it is not needed). Where as C++ is the exact opposite. This brings across the important point about "runtime" exceptions. In Java they do not need to be specified in an exception specifier, they will just propagate out the function and may be handled somewhere (or crash out the main entry point). In C++ if you add some exceptions to the specifier, but forget/omit the runtime ones, then your program will be terminated early, there is no option for other code to actually handle that exception (std::bad_exception in my opinion is a bad substitute in this situation). What is the benefit of exception specifiers that can not be provided with documentation (I am sure there are some or they wouldn't have been added to the standard, but i have become dis-enchanted with exception specifiers)? The only thing i can think of is optimization, and that is discussed by the boost page on exception specifiers mentioned earlier. It has been a while since i have looked in detail on this topic. Initially EDoc++ was written so that i could then go and write all my C++ code with exception specifiers and then use EDoc++ to enforce them (I wanted to reproduce what Java had for C++). But even though EDoc++ can enforce such usage, to actually write code that lists all its exception specifiers is just WAY too much work and there is no or little gain that i can see from doing so. As a result, EDoc++ has evolved to cover different aspects of exception usage analysis and the initial purposes of it i rarely use. What i mentioned in an earlier post is that rather than a function specify what it can throw, i propose that for the C++ community a more useful compile time assertion is to allow code that uses a function to define what exceptions it can deal with that function throwing. I.e. moving the contract from the used to the user. I noticed when i started to become aware of writing exception safe code, that i would be acutely aware that certain portions of code i was using needed to have particular exception requirements (Such as the nothrow destructor, or i use certain members of the std::list or pointers as they have a number of no-throw operations). I can not enforce that say some client code include exception specifiers, but i can modify my code to define the contract that i require of them. Then i could use EDoc++ or some other similar tool to tell me if those contracts have not been met. If they are not, then i either request change in the client code or change the way i use them. With all this in mind, i think that the proposed warning will not be used by many and will not shape the future of C++ due primarily with the issues inherent in the C++ language definition of how exception specifiers work. I do however think as i mentioned before that it would make a great project to learn more about GCC internals and would encourage giving it a try on those grounds. Brendon.
