Re: C++0x/1x exception specifications proposal: Compile-time checked
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)
{
// ...
}
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]