C++0x/1x exception specifications proposal: Compile-time checked

[richard]

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.

 

[Erik Wikström]

[...]

My advice to you is to take some time to study how it is done in Java,
C++, and possibly a few other languages, and also to read the articles
on the subject that is available on the 'net. Then sit down and think it
all through and finally present your idea in comp.programming (or maybe
comp.std.c++), because it seems to me like this is starting to go off-
topic (since this is really more related to language design than C++).

 

[Ioannis Vranos]

My advice to you is to take some time to study how it is done in Java,
C++, and possibly a few other languages, and also to read the articles
on the subject that is available on the 'net. Then sit down and think it
all through and finally present your idea in comp.programming (or maybe
comp.std.c++), because it seems to me like this is starting to go off-
topic (since this is really more related to language design than C++).

Thanks for your advice. I 'll spend some time thinking on the subject
and provide a complete proposal. I opened this discussion thread to see
what others think, while I was thinking, like an open source project
kind of thing.

I am not going to check how Java does it, I am not willing to learn Java
right now. I had my time with .NET back in VS 2002/2003 era, learned
..NET multithreading and stuff, and more or less I consider it as a lost
time. Java is a language syntax + framework, like C#/CLI/.NET, VB/.NET
and perhaps C++/CLI/.NET.

Anyway, my approach in simple words is that a function/member function
is like a level, its compile-time _throw specification denotes the
exceptions the specific function/member function may throw itself and
not the "inherited" exceptions of other called functions/member
functions. And thus it requires at least one corresponding throw
some_exception; statement for every _throw(some_exception), inside the
function/member function definition, checked easily at compile-time.

The _nothrow keyword denotes which "inherited" exceptions are caught
inside the definition of the function/member function and requires at
least one catch(some_exception); statement inside the function/member
function definition or a catch(...), easily checked at compile-time.

The non-caught exceptions types are "accumulated" at compile time and
with the use of the :exceptions keyword the compiler will inform us with
a message which uncaught exceptions may be thrown from a specific
function call in the style:


int main()
{
some_func() :exceptions;
}


so as to create the needed catch() blocks.


Anyway, I will write all down and come back with it after few weeks. In
the meantime, I will check for any replies in this thread.