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.

### 1108. thread.req.exception overly constrains implementations

Section: 32.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.

Discussion:

The current formulation of 32.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 mapping is always performed, even if the resultant value is never used.

- 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:

- `error_code` holds the original error produced by the operating system.
- `error_condition` and the generic category provide a set of well known error constants that error codes may be tested against.

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 19.5.3.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 32.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]