This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of C++11 status.
Section: 33.2.2 [thread.req.exception] Status: C++11 Submitter: Christopher Kohlhoff Opened: 2009-04-25 Last modified: 2016-01-28
Priority: Not Prioritized
View all issues with C++11 status.
The current formulation of 33.2.2 [thread.req.exception]/2 reads:
The error_category of the error_code reported by such an exception's code() member function is as specified in the error condition Clause.
This constraint on the code's associated error_categor means an implementation must perform a mapping from the system-generated error to a generic_category() error code. The problems with this include:
The original error produced by the operating system is lost.
The latter was one of Peter Dimov's main objections (in a private email discussion) to the original error_code-only design, and led to the creation of error_condition in the first place. Specifically, error_code and error_condition are intended to perform the following roles:
Any mapping determining correspondence of the returned error code to the conditions listed in the error condition clause falls under the "latitude" granted to implementors in 126.96.36.199 [syserr.errcat.objects]. (Although obviously their latitude is restricted a little by the need to match the right error condition when returning an error code from a library function.)
It is important that this error_code/error_condition usage is done correctly for the thread library since it is likely to set the pattern for future TR libraries that interact with the operating system.
[ Batavia (2009-05): ]
Move to Open, and recommend the issue be deferred until after the next Committee Draft is issued.
[ 2009-10 post-Santa Cruz: ]
Move to Tentatively Ready.
Change 33.2.2 [thread.req.exception] p.2:
The error_category (188.8.131.52) of the error_code reported by such an exception's code() member function is as specified in the error condition Clause.