Re: C++0x/1x exception specifications proposal: Compile-time checked
On 21 Jan, 15:12, "Andrew Koenig" <a...@acm.org> wrote:
The problem with this is that *any* expression that has the capability of
causing undefined behavior has the capability of throwing any exception. In
particular, this property means that an implementation is permitted to
extend the language so that arithmetic errors, such as division by zero,
throw exceptions.
What would you have such an implementation do about an arithmetic operation
inside a throw() function that might overflow? If the compiler complains
about it, it is rejecting a program that might have nothing wrong with it.
If it doesn't, then you need to figure out how to change your requirement to
permit such behavior.
Or, put another way, "I've just invoked undefined behaviour, and it
hasn't done what I expected". ;-)
Surely the standard should be written in such a way as to make sense
when the user isn't invoking undefined behaviour. That is, if you had
static exception checking, the following should compile cleanly:
int divide( int x, int y )
static throw() // or whatever syntax you adopt
{
return x / y; // But what if y == 0?
}
If y == 0, then you've got undefined behaviour. If the compiler
chooses to define it to this behaviour to throw a "divide by zero"
exception, then that's fine. However the compiler then also needs to
define what happens when it encounters an exception specification.
And the obvious choices seem to be: that it passes through the ES; or
that it is caught by the ES and std::unexpected (and probably then
std::terminate) is called. Personally, I think I'd want the latter,
because I wouldn't want anything to emerge from a function declared
"throw()".
But the good thing about undefined behaviour is that it's undefined.
Anyway, are there any implementations that throw an C++ exception on
divide by zero? Or on dereferencing a null or invalid pointer? I
know about MSVC's "structured exceptions", but when I last looked
(some time ago: I don't really use Windows), these weren't like C++
exceptions in that they weren't caught by "catch (...)" or by a
"throw()" ES.
--
Richard Smith