I have for a while been working on a tool that performs static analysis of exception propagation through C/C++ code. It is very close to complete (I estimate the first release within the month).
Implementing static analysis of C++ exception propagation in g++ alone is not really possible well at least not really feasible. The tool i have been developing uses g++/gcc to obtain information about the code so i can construct a complete pessimistic callgraph along with info about exception usage, but it does not do it at compile time, rather it has to perform the analysis at the equivalent to the linking stage to get ALL the necessary information to construct this callgraph accurately. The problem is for things like function pointers/virtual functions, until you know exactly what code goes into a particular application you can not be sure exactly what to expand the calls to. I.e. you will only get a subset of possible calls from a single translation unit. To get the full set of possible calls you need to look at ALL code that goes into a particular application. (This becomes a nightmare to manage with especially plugins and the like) If ALL C++ code implemented a thing like in Java (Which i think is what you are describing) where you can be guaranteed that a function only throws certain exceptions and the compiler mandates this, then you can achieve the same sort of results in a single translation unit, however getting every project that uses C++ to adopt such techniques is just not going to happen and without having all projects adopt this the usage will become very difficult. I.e. you will either have to wrap the function calls inside of try/catch blocks to meet the strict requirements. Using something like that could be a nightmare... There would be catch blocks all over the place that are used to filter out possible exceptions from other peoples code that you just don't know if they are going to occur. And what do you do if an exception does occur that you were not expecting? I think the idea is a great one. It works very well in Java. I still dont understand why the C++ standard adopted the current throws() mechanism (Who thought that terminating a program based on that particular exceptoin condition that the compiler cant check for you was a good idea? Hmm. I dont know a anyone who make use of the throws() clauses very often unless they usually do throws() and do a catch all and are not necessarily sure what exactly to do with what they caught anyway) I think the whole mechanism comes from the history of the language and so it has a semi-useful technique unlike Java where the throws() clause works well. I have written this application so that i can use the standard C++ mechanisms for indicating the exceptions that can occur, then i can run my code through this tool and it will notify me of places where an exception may occur that is contrary to what i have specified. This means i can use the standard mechanisms and get the equivalent of a "compile error" from my application when my assumptions are incorrect. It basically assures me that I wont have my program terminate because of this problem. Anyhow, I could talk for a while about this... But if you are interested more in this application then there is a partially complete website: http://edoc.sourceforge.net/ As i said it is not yet complete but it is getting close. I will be updating the website and the documentation again once i have completed modifying the code. The only way to download the code at the moment is from CVS and i would not recommend that just now. So it might be best to wait and give it a try. You can read the "rough" manual for now to get an idea of what EDoc++ can and cant do and how to use it. I will hopefully be posting to this list later a shameless plug for this application when it is all ready (I was going to ask the maintainer first). I am interested in feedback on how it can be improved, but this thread came up and i just could not pass the opportunity... Brendon. Sergio Giro wrote: > Maybe that the option you suggest > >> This is best >> done with something like -fstatic-exception-specifications or maybe - >> Wexception-specifications -Werror. > > is ideal, but it seems to me not practical at all. Every stuff using > the throw qualifier as specified in the standards will not work. If an > inline method in a standard header is > theInlineMethod (void) throw () { throw theException(); }; > this will not even compile... > Of course, using an extension as the one I propose, some of the > standard methods must be wrapped if you want to use the new qualifier > in order to track the possible exceptions that the methods may arise, > but I think it is quite more practical to wrap such methods than to > modify the headers... > In addition, the semantic meaning is not the same: a > throw (a,b,c) qualifier indicates that you are able only to catch the > exceptions a, b and c, and that every other exception will be seen as > std::unexpected. Nevertheless, a > _throw(a,b,c) qualifier should indicate that the only exceptions that > can arise are a, b and c . > With respect to this: >> If you wanted finer control, >> having an inheritable attribute that says, please statically check >> exception specifications for all member functions in this class and/ >> or on the function would be better than replicating the entire >> mechanism. > I think that a lot of information can be obtained by using existing > mechanisms. The calculation of the exceptions a module may arise under > pessimistic assumptions is rather easy, if you don't allow template > exceptions to be used in the _throw qualifier. I think that the hard > step is to put it into gcc. I will be grateful for any advise on how > to start looking add in order to implement this new feature. > Cheers, > Sergio > > On 3/30/07, Mike Stump <[EMAIL PROTECTED]> wrote: >> On Mar 30, 2007, at 11:59 AM, Sergio Giro wrote: >> > The errors mentioned are compile errors, >> >> So, you want a strict subset of the language standard. This is best >> done with something like -fstatic-exception-specifications or maybe - >> Wexception-specifications -Werror. If you wanted finer control, >> having an inheritable attribute that says, please statically check >> exception specifications for all member functions in this class and/ >> or on the function would be better than replicating the entire >> mechanism. >> > > > >
