Adding to G++: Adding a warning on throwing unspecified exceptions.

Simon Hill yacwroy@gmail.com
Wed Sep 24 15:19:00 GMT 2008


Thanks for all the links. I knew there were people wanting this but I
didn't quite get how big an issue it was.


Brain Dessent wrote:
> You're essentially trusting that all
> exception specifiers for every function in the program and *all* library
> code are always present and always correct which is a huge leap of faith
> that I don't think is supported by reality.

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.


Brain Dessent wrote:
> The general consensus is that doing this at compile time cannot give you
> anything useful, because the compiler can only see one compilation unit
> at a time and so the only thing it can know of all the downstream
> functions that are in other CUs is what is provided in the exception
> specifiers of the prototypes.

So, once the other CUs adhere to their prototype exception specifiers,
this becomes OK. I definately intend all of my own CUs to adhere.
Also, you rely on CUs doing what they say in all other means (eg not
modifying const-passed references), why not rely on their exception
specifiers as long as they say you can. And if only some (ie your own)
CUs adhere, that's by no means worse than none adhering (as long as
you are aware that some don't).


> You should certainly look at EDoc++, mentioned in the above threads.
http://edoc.sourceforge.net/
This is definitely interesting, however our goals are a bit different.
EDoc++ is about checking that there is no chance a thrown that
actually exists in code can propogate to somewhere where it will
terminate the app due to being unhandled. It's not about enforcing
code requirements. For example, foo() throw() can call bar()
throw(zug) as long as it doesn't actually throw a zug, or call
anything that does. I would like an environment where the above
example is considered poor practice.


One thing I read there that concerned me was when it was said that
some compilers do "pessimizations" such as not inlining functions with
throw clauses or placing try/catch blocks around calls to these.
I hope that these compilers aren't mainstream. Also, I don't think
that consideration of current bad implementations should factor into
the decision. If people decide to use exception specifications more
these compilers will either get fixed or become slower.


So overall:
- Lots of people request it (for good reasons or bad). Even bad
reasons mean there's an advantage from providing this as an option, ie
showing that it doesn't do what they want.
- Nobody has yet shown me any fundamental problems with implementing
this, apart from my typedefs of function pointers not being allowed
exception specifications which, while annoying, can be avoided.
- It helps code comply with what it says (if you read the throw()
clause in what seems to be its spirit: as an indication of what may be
thrown).
- It's fully optional, and off by default.
- The only real issue is that it will complain about third party code
that doesn't yet "comply". But by this same token this helps third
party code become "compliant" if the authors desire it to be. There's
also the possibility of adding a modification that could ignore calls
to functions declared inside a whitelist of headers like <vector> to
further reduce this.
- GCC probably doesn't do the above pessimizations (I guess I'll have
to look into this).
Where's the downside?



More information about the Gcc mailing list