Re: C++0x/1x exception specifications proposal: Compile-time checked
Ioannis Vranos wrote:
I think we are very close to finish it. I think We can make safe-solid
source code.
Please everyone to contribute, so as to make an excellent compile-time
checking exception specification mechanism.
Ioannis Vranos wrote:
Added more info:
Ioannis Vranos wrote:
A revised version of my proposal (version 1.9):
Design ideals:
1. *Loose* compile-time checking of throw compile-time
specifications. The compiler reports an error if it can detect one.
If it can't detect one, the compiler does not report any error. That
implies, it is up to the implementation on how much it will try to
detect such errors, apart from the obvious cases.
2. Current C++03 code is not affected by this proposal. The default
is no compile-time checking is done, if no throw compile-time
specification is provided.
3. Compile-time checking of throw compile-time specifications is done
separately from throw run-time checking. That is, "throw"
specifications remain as they are, run-time checked. New keywords are
introduced for compile-time checking. There probably can be prettier
names, but here I choose the keywords "_throw" and "_nothrow" for
this purpose.
[REMOVED]
4. The compile-time checking is *loose*, and will issue a compile-time
error, only if it detects that a *specific* exception can be thrown that
violates the _throw/_nothrow specifications, and will not be based on
declaration hierarchy.
The above imply that:
1. The loose compile-time checking of _throw/_nothrow specifications
is defined explicitly by the programmer if he chooses to do so. The
default is no compile-time checking.
2. If an unexpected exception is thrown, it propagates as it didn't
violate the compile-time _throw/_nothrow specifications, that is with
no run-time side-effects. In other words, if the compile-time
exception-specification is violated at run-time, std::unexpected() is
*not* invoked.
3. The loose compile time checking will eventually lead to better
error handling code, that is more safe code without any additional
run-time cost.
Details:
1. The possible uses and meanings of "_throw" are:
_throw(), _throw(void): The function or member function does not
throw any exception.
_throw(some_exception1, some_exception2): The function or member
function may throw one of those exceptions. It may throw more that
are defined in the _nothrow specification, but does not report them
as a compile-time error (loose meaning).
_throw(...): Equivalent to non-existence of compile-time _throw
specification. That is:
void somefunc()
{
// ...
}
is equivalent to
void somefunc() _throw(...)
{
// ...
}
_throw(...) is just more explicit.
2. The possible uses and meanings of "_nothrow" are:
_nothrow(), _nothrow(void): Equivalent to non-existence of
compile-time _nothrow specification. That is the following are
equivalent:
void somefunc()
{
// ...
}
void somefunc()
{
// ...
} _nothrow()
void somefunc()
{
// ...
} _nothrow(void)
_nothrow(some_exception1, some_exception2): The compiler will ignore
some_exception1 and some_exception2 and will not provide any
compile-time error, if it detects that any of these two violate any
_throw specification.
Example:
void somefunc() _throw(std::bad_alloc, my_app::graph_range_error)
{
// ...
} _nothrow(std::out_of_range)
3. _nothrow(...): Ignore all exceptions. Compatible only with the
_throw() specification.
Example:
void somefunc() _throw()
{
// ...
} _nothrow(...)
Things remaining to be solved:
void somefunc() _throw()
{
throw std::bad_alloc;
}
is probably an obvious compile time error case.
My current direction of thought in compile-time exception specifications:
The compile-time exception specifications of each function and member
function, are about declaring any *additional* exception the specific
function or member function will throw, and not about redeclaring the
"inherited" exceptions.
That is, each function/member function is a level, and each level
declares two things: The exceptions it can throw by itself using the
_throw keyword, and the "inherited"exceptions it can handle, that are
denoted with the _nothrow keyword.
At compile-time, those exception specifications are *accumulated*, and
at the caller level we specify (the caller function or member function),
we get a compile-time result of the exceptions that it can receive.
That is:
template <class T>
void somefunc(T &a) _throw()
{
// ...
}
Here somefunc() indicates that itself will not throw any additional
exceptions. One of its arguments may throw one, but itself will throw no
exception. That is, the compile-time exception specification of this
template function is correct.
At compile-time, those exception-specifications will be *accumulated* up
to the desired level of exception handling, where we will know the exact
types of exceptions we can handle.
Another example with a template:
template <class T>
void somefunc(T &a) _throw()
{
// ...
} _nothrow(std::bad_alloc)
This indicates that somefunc() will not throw any exceptions itself,
while it also handles the case of std::bad_alloc. This means
std::bad_alloc will stop being *accumulated* at the compile-time
exception checking.
==> So this is what it remains to be resolved:
How can we retrieve the accumulated exception types information, at a
desired level where we want to handle them, with compile-time messages?
Example:
void somefunc2() _throw(graph_exception)
{
// ...
}
void somefunc1() _throw(time_exception)
{
somefunc2();
} _nothrow(std::out_of_range)
// The question that remains to be solved is: How can we find out at the
// point of somefunc() call in main(), that we can receive
// time_exception and graph_exception, whose info has been *accumulated*
// at compile-time by the use of _throw/_nothrow compile-time
// specifications, so we can handle them there?
int main() try
{
somefunc1();
}
catch(time_exception)
{
// ...
}
catch(graph_exception)
{
// ...
}
The solution that I propose on this, is the keyword :exceptions or
:_exceptions:
void somefunc2() _throw(graph_exception)
{
throw graph_exception();
}
void somefunc1() _throw(time_exception)
{
somefunc2();
throw time_exception();
} _nothrow(std::out_of_range)
int main()
{
somefunc1() :exceptions;
}
at compile-time it will produce a compiler message, something like:
"main()::somefunc1() may throw exceptions:
somefunc1()::somefunc2()::graph_exception, somefunc1::time_exception".
After we write our exception handlers, we can remove the keyword
":exceptions" from somefunc1(); statement in main(), and thus main becomes:
void somefunc2() _throw(graph_exception)
{
throw graph_exception();
}
void somefunc1() _throw(time_exception)
{
somefunc2();
throw time_exception();
} _nothrow(std::out_of_range)
int main() try
{
somefunc1();
}
catch(graph_exception)
{
// ...
}
catch(time_exception)
{
// ...
}
Compiler checks/errors:
Where the source code is available to the compiler, any
_nothrow(some_exception) specification at a function/member function,
must have at least one equivalent catch(some_exception) or catch(...)
exception handler at the function definition.
For example:
void somefunc() _throw()
{
int *p= new int[10];
} _nothrow (std::bad_alloc)
should be flagged as a compiler error, because there is no
catch(std::bad_alloc) or catch(...) exception handler at the function
definition.
The following should be correct:
1 .
void somefunc() try _throw()
{
int *p= new int[10]
} _nothrow (std::bad_alloc)
catch(std::bad_alloc)
{
// ...
}
2.
void somefunc() try _throw()
{
int *p= new int[10]
} _nothrow (std::bad_alloc)
catch(...)
{
// ...
}
3.
void somefunc() try _throw()
{
int *p= new int[10]
} _nothrow (...)
catch(...)
{
// ...
}
Where the source code is available to the compiler, any
_throw(some_exception) specification at a function/member function, must
have at least one equivalent throw some_exception(); statement.
Remember each function/member function is a level, and its _throw
specifications are about exceptions they explicitly throw, and not about
"inherited" exceptions from other function/member function calls.
For example:
void somefunc() _throw(std::bad_alloc)
{
}
is a compiler error.
void somefunc() _throw(std::bad_alloc)
{
throw std::bad_alloc();
}
is correct.
The following should be correct:
void somefunc() _throw()
{
vector<int> vec(10);
for (vector<int>::size_type i= 0; i< 10; ++i)
vec.at(i)=5;
}
because it doesn't throw any exception by itself.
void somefunc() try _throw()
{
vector<int> vec(10);
for (vector<int>::size_type i= 0; i< 10; ++i)
vec.at(i)=5;
} _nothrow (std::out_of_range)
catch(std::out_of_range)
{
// ...
}
is correct and removes std::out_of_range from the exception
"accumulation" list.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]