Created on 1999-06-08.00:00:00 last changed 255 months ago
Proposed resolution (10/00):
Replace 14.5 [except.spec] paragraph 7 with the following:
A function is said to allow an exception of type E if its exception-specification contains a type T for which a handler of type T would be a match (14.4 [except.handle]) for an exception of type E.
The standard is inconsistent about constness inside exception specifications.
struct X {};
struct Y:X {};
const Y bar() {return Y();}
void foo()throw(const X)
{
throw bar();
}
It is unclear whether calling foo will result in a call
to std::unexpected. According to
14.5 [except.spec] paragraph 7,
only two cases are treated
specially with regard to inheritance: If "class X" appears in the
type-id-list, or if "class X*" appears in the
type-id-list. Neither is
the case here, so foo only allows exceptions of the same type
(const X). As a result, std::unexpected should be called.
On the other hand, the intent of exception specification appears to allow an implementation of this example as
void foo()
try{
throw bar();
}catch(const X){
throw;
}catch(...){
std::unexpected();
}
According to
14.4 [except.handle]
,
this replacement code would catch the exception, so
std::unexpected would not be called.
Suggested resolution: Change 14.5 [except.spec] paragraph 7 to read
A function is said to allow all exception objects of all types E for which one of the types T in the type-id-list would be a handler, according to 14.4 [except.handle] .
| History | |||
|---|---|---|---|
| Date | User | Action | Args |
| 2003-04-25 00:00:00 | admin | set | status: dr -> tc1 |
| 2000-11-18 00:00:00 | admin | set | status: ready -> dr |
| 2000-05-21 00:00:00 | admin | set | messages: + msg332 |
| 2000-05-21 00:00:00 | admin | set | status: drafting -> ready |
| 2000-02-23 00:00:00 | admin | set | status: open -> drafting |
| 1999-06-08 00:00:00 | admin | create | |