Created on1999-06-08.00:00:00 last changed277 months ago
Proposed resolution (10/00):
Replace 14.5 [except.spec] paragraph 7 with thefollowing:
A function is said toallow an exception of typeE ifitsexception-specification contains a typeT forwhich a handler of typeT would be a match (14.4 [except.handle]) for an exception of typeE.
The standard is inconsistent about constness inside exceptionspecifications.
struct X {}; struct Y:X {}; const Y bar() {return Y();} void foo()throw(const X) { throw bar(); }It is unclear whether callingfoo will result in a calltostd::unexpected. According to14.5 [except.spec] paragraph 7,only two cases are treatedspecially with regard to inheritance: If "class X" appears in thetype-id-list, or if "class X*" appears in thetype-id-list. Neither isthe case here, sofoo 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 toallow an implementation of this example as
void foo() try{ throw bar(); }catch(const X){ throw; }catch(...){ std::unexpected(); }According to14.4 [except.handle],this replacement code would catch the exception, sostd::unexpected would not be called.Suggested resolution: Change14.5 [except.spec] paragraph 7to read
A function is said toallow all exception objects of alltypesE for which one of the typesTin thetype-id-list would be a handler, according to14.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 | |