Re: C++0x/1x exception specifications proposal: Compile-time checked
When speaking about the semantics of an exception specification, I will
refer to an absent specification as a 'throw all' specification.
Richard Smith wrote:
I think you could do this quite effectively, and in a way that doesn't
break in templates, by adding optional static checking of ESs and
optional implicit generation of ESs. For the sake of argument, I'm
prefixing the ES with "static" for a statically-checked ES, and
putting "auto" as the only thing in parentheses for a implicit ES:
exception-specification:
static[opt] throw( type-list-id[opt] )
static[opt] throw( auto )
To implicitly generate an ES for a function, the compiler looks at the
ESs of all of the functions called and throw expressions (even in
provably unreachable code) other than in handlers. We can pretend
that a re-throw expression is just a call to a function with no ES,
and other throw expressions are calls to a function with one type in
their ES: the type being thrown. Functions and throw expressions
within try blocks have their ESs modified by any no-throw handlers
(catch blocks). A no-throw handler is a handler that only calls
functions with a no-throw ES.
I agree with Sean Hunt that a re-throw that is not lexically part of a
catch-clause should not render a function to be implicitly 'throw all'.
<snip - union of exception specifications>
Static checking is now easy: if implicit ES is non-existent (i.e.
something called a function without an ES and didn't catch(...)), or
if the implicit ES is weaker than the supplied one, it is an error.
The former means that it makes sense for a ES to be both statically-
checked and implicitly-generated: i.e. a "static throw(auto)"
declaration: this just checks that the ES exists.
How does this work recursively if a function with an implicitly-
generated ES calls another one with an implicitly-generated ES,
perhaps in a different translation unit?
As a implicitly-generated ES can only be generated when the function
definition is visible, a function *declaration* with a implicitly-
generated ES behaves as if it does not have an ES; but a function
*definition* with an implicitly-generated ES does have one. Thus,
void f() throw(auto);
// ...
void f() throw(auto) { throw A; }
is equivalent to
void f();
// ...
void f() throw(A) { throw A; }
except that you won't get an error about differing exception
specifications.
This would cause a problem if you call a function with throw(auto) for
which the definition is not visible.
For example:
void f() throw(auto);
void g() static throw(auto)
{
f();
}
Under the current proposal, this would result in a diagnostic that the
calculated exception specification for g() is 'throw all' and that is
not allowed for a throw(auto) function.
To avoid this, I would propose the following changes:
- If the definition of a throw(auto) function is not visible, the
throw(auto) specification is interpreted as specifying a bounded set of
unspecified exceptions. These unspecified exceptions will not match any
explicitly mentioned exceptions in a caller (either in the exception
specification or in a catch clause), but they can be added to the
automatically generated set of exceptions for the purpose of
calculating a throw(auto) specification.
- If the definition of a throw(auto) function is visible, the
throw(auto) specification is replaced with the calculated throw
specification.
This way, the example above would be valid, while the one below will be
rejected.
void f() throw(auto);
void g() static throw(std::bad_alloc)
{
f();
}
voif f() throw(auto)
{
int* i = new int;
}
/* Switching the definitions of f() and g() would make this code valid
*/
How would this work in practice?
Adding no-throw ESs effectively really needs to be done from the
bottom up -- starting with the lowest level libraries. So it would be
good to see no-throw ESs in the standard library where that guarantee
exists (e.g. vector::size, shared_ptr copy constructor, and
particularly on iterator operations). Light-weight algorithms
probably just want a throw(auto) ES adding, and heavier duty code
(e.g. large parts of IOStreams, Locales) probably don't want any ESs.
I see a couple of problems with the practicalities.
The biggest one is C language APIs. We can not expect that libraries
that only provide an API for the C language will start adding exception
specifications to their headers.
I see two possible solutions to this problem
- we create a syntax to provide the exception specification en-masse,
like it is currently for the language linkage specification (extern "C"
{ ... }), or
- as an exception to the general rules, extern "C" functions without an
exception specification are assumed to have a specification of throw().
<snip - interaction with concepts>
To me this sounds quite a workable way of improving exception
specifications. Although it's all formulated in terms of general ESs,
it's really only the no-throw case that I think is of use. But given
the starting point, it seems simpler to formulate it this way.
The big benefit is overloading based on whether something can throw an
exception -- i.e. being able to supply several versions of an
algorithm with different complexities depending on what might throw.
It's entirely backwards compatible: ordinary "throw(foo)" declarations
are unchecked and result in std::terminate as today. You don't pay
for what you don't use: if you don't use implicitly-generated or
statically-checked ESs, they are not computed; nor do they need
computing for functions with implicitly-generated ESs that you call.
Does anyone have any thoughts on it?
In general, I rather like it.
There are some details that I don't agree on, and the interaction with
concepts and the overloading on ES goes a bit over my head, but it is
at least better than the other proposals I have seen in this direction.
The main advantages for me are that it is optional, and that it does not
overly burden the authors of templates.
Bart v Ingen Schenau
--
a.c.l.l.c-c++ FAQ: http://www.comeaucomputing.com/learn/faq
c.l.c FAQ: http://c-faq.com/
c.l.c++ FAQ: http://www.parashift.com/c++-faq-lite/
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]