Jason Cipriani wrote: > One feature that I have > always desired the most in a C++ compiler is strict enforcement of > throw() clauses. Since you seem to be well aware of the design of C++ exceptions you should realize why this is a near impossibility. In order for the compiler to enforce a throw declaration, it would have to have complete knowledge of the entire outbound call graph of the function. Two things stand in the way of this: separate compilation and function pointers/virtual functions. The problem of separate compilation (i.e. that the compiler only has local knowledge of a given translation unit at any time) can somewhat be dealt with by using gcc --combine, but that's more of a crutch. It won't fix the issue that necessitated separate compilation in the first place: the explostion of complexity as the size of one "unit" grows. (And here I'm not speaking at all of the human factors of keeping source units small and maintainable, I'm strictly referring to the algorithmic complexity experienced by the compiler.) Longer term, the gcc LTO project will eventually provide a better infrastructure for whole-program optimizations, but it will still not be able to see past library boundaries. That might not be a problem if like you say C++ had been more Java-like and required accurate throw declarations from the beginning. But there is just no reasonable way to expect that now, so from a compiler standpoint the only way to implement enforcement of throw declarations would be to "see down into" all library code (unrealistic for all but perhaps embedded applications) or to rewrite all library code to include accurate throw declarations in their headers and then tell the compiler it can trust them. Either way, it's a ton of work. And this hasn't even begun to address the issue of function pointers and virtual methods, where the call graph can't even be known at compile time. I'm sure you could construct a pathological testcase without too much effort for which it would be provably impossible to enforce throw declarations at compile or link time. However, you may be interested in Brendon Costa's EDoc++ which consists of a hacked up gcc that embeds additional exception and callgraph data into the objects, and a post processing tool to recover, combine, and analyze it all at link time. <http://edoc.sourceforge.net/> Brian
