In article <fm***********@ulysses.noc.ntua.gr>,
iv*****@no.spamfreemail.nospam.gr says...
Perhaps a mechanism can be introduced in the C++0x/1x standard,
something simple like defining a function as:
void somefunc(void) throw()
[ ... ]
and getting a compile time error saying something like:
"Error: void somefunc(void) throw(): Wrong exception specification.
somefunc can throw std::bad_alloc, std::range_error".
That is make the compiler to check exception specifications for errors too.
This is next to impossible in practice. In particular, the compiler
doesn't have anything to check against with externally defined functions
-- i.e. you include a header with an exception specification, but the
compiler has no access to the implementation of the "stuff" in that
header (unless it happens to be included inline).
In practice, doing so probably wouldn't be a good idea anyway. Java has
checked exceptions, where the compiler does (more or less) what you're
advocating. Experience has shown (repeatedly) that while this seems like
a good idea, it almost never works well in practice.
In the end, exception specifications are an anti-pattern -- something
that initially seems like a good idea, but in the long run ends up
causing far more problems than it solves.
One of the basic ideas of exception handling is that it sets up more or
less a "tunnel" from the place an exception is thrown to the place it is
caught, and any intermediate layers need not worry about it (beyond
being exception safe). Exception specifications (especially enforced as
you're advocating) require that all intermediate levels DO pay attention
to the exceptions that propagate from the lower levels, though the
intermediate layer has no real interaction with the exception itself at
all. Worse, an intermediate layer might easily work with a function via
a pointer, in which case it simply has no way of knowing what exceptions
might be thrown through it by that function. You could make the
exception specification part of the function signature, so it could only
take pointers to functions that threw from a limited selection of
exceptions, but this would frequently be quite limiting. In many cases,
such call-back functions (and such) haven't even been contemplated when
the code that uses them is written, so it's essentially impossible for
them to even guess at what exceptions they might throw.
In addition, templates and exception specifications are essentially
impossible to blend. A typical template can throw most (if not all) the
exceptions that can be thrown by the type over which it is instantiated
-- but an many cases, nobody has yet imagined the type over which it
will be isntantiated when the template itself is written.
I'll repeat: exception specifications are an anti-pattern. They're
nearly always bad now, and having the compiler attempt to enforce them
would make them even worse.
--
Later,
Jerry.
The universe is a figment of its own imagination.