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

Brendon Costa bcosta@avdat.com.au
Sat Sep 27 14:03:00 GMT 2008


> 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.



More information about the Gcc mailing list