> I agree that it won't be very useful initially due to lots of third > party code like boost neither defining nor adhering exception > restrictions 100% of the time (STL may be guilty also). However, this > is a catch 22. Why not provide the mechanism for verifying exception > specifications so that these libraries can, in future, become fully > compliant? It won't take much work, especially when you can get a > warning telling you exactly what you need to change, and the only > thing you need to do 99% of the time is add throw() clauses to > definitions and declarations. I bet you could get boost & STL > compliant within a week even if they had 0 throw() clauses to begin > with. > > One of the problems i see with this is generic template classes like the STL containers. The author of the template class or container can't know what types of exceptions will be thrown from them, so you must define them as being able to throw all exceptions (which is how they are currently). Then if those containers are used all over the place then you are back to square one. Personally i am starting to see that usage of the exception specifier in C++ is "almost" useless (I find them a bit more useful with EDoc++ but i still only use them very rarely).
I initially thought the same way as you are now, but in the end decided it was necessary to construct a complete list of exceptions that can be thrown before then applying such rules. This is what EDoc++ does. It first calculates all possible exceptions, then it performs all sorts of analysis to enforce things like exception specifiers (and much more). After developing EDoc++, i have also realized how pervasive exceptions can be in C++ code, which works against the sorts of checks that can be done within a single translation unit. I had to go to lengths to provide a "suppressions" system for EDoc++, simply because almost all code can throw all sorts of exceptions i had never heard of before. A developer "generally" is not interested in exceptions like: __gnu_cxx::recursive_init. But after writing EDoc++ i found exceptions like this turn up all over the place, though they should not occur in normal operation... With all this said though. If your purpose is to learn more about GCC internals, then i think it would be a good project to undertake to achieve that. You may have to do so though, with the understanding that the maintainers may not choose to accept your patch into the official GCC release. I don't know if they would or not, as i am not a GCC maintainer but it would be worth getting clarification before doing the task. On a slight side note, there is a feature i have been postponing from EDoc++ until "the distant future". It is to provide "meta-data" or code "markup" which can be used to enforce certain restrictions on code being used. This is primarily of use for defining a "contract" when writing template code that wants to define a certain "exception guarantee". For example, i assume you are familiar with the various "guarantees" that have been described in literature about exceptions in C++ (if not then it is worth looking up. It sure opened my eyes to writing safer and better code in the presence of exceptions). To make some generic container satisfy the "strong guarantee" will require certain restrictions on the type used to instantiate the template. A good example of this is that the destructor for the type must not throw an exception. For a given generic implementation, there may be additional restrictions as well. If these restrictions are not met, then the container will no longer meet the "strong guarantee". I wish to define a method of marking up source code such that those requirements are described inline in the code of the template implementation such that someone who instantiates the template with a particular type can then run EDoc++ over their code and be warned when that particular instantiation may break the requirements. Anyhow, this is a preliminary idea and i just don't have the time now to look at implementing it. It will likely require changes to the C++ parser and front end to insert extra nodes into the tree for this markup. I am also not sure if others would accept such a modification into the official GCC release unless it was generic enough to be used for other purposes (maybe such as providing optimization hints for certain segments of code or other forms of markup). Thanks, Brendon.
