1108. thread.req.exception overly constrains implementations

Section: 33.2.2 [thread.req.exception] Status: C++11 Submitter: Christopher Kohlhoff Opened: 2009-04-25 Last modified: 2016-02-10

Priority: Not Prioritized

View all issues with C++11 status.

Discussion:

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 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 22.5.2.5 [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.

Proposed resolution:

Change 33.2.2 [thread.req.exception] p.2:

-2- The error_category (19.5.1.1) of the error_code reported by such an exception's code() member function is as specified in the error condition Clause. The error_code reported by such an exception's code() member function shall compare equal to one of the conditions specified in the function's error condition Clause. [Example: When the thread constructor fails:


ec.category() == implementation-defined // probably system_category
ec == errc::resource_unavailable_try_again // holds true

end example]