JTC1/SC22/WG21
N2538
Removal of System error support.
Document Number: N2538=08-0048
Date: 2008-02-25
Author: Benjamin Kosnik <bkoz@redhat.com>
Overview of Changes.
Remove specification of System error components in section 19.4.
Replace use of System error components in the current draft (N2521).
A quick survey shows current use limited to the specification of the
std::system_error exception class in throw clauses, which can be
replaced by using its base class (std::runtime_error) as
detailed below.
Rationale.
1. Initial support for the facilities detailed in 19.4 was predicated
on use cases in several libraries: filesystem, network, and
threads. Of these proposals, only threads will be in C++0x, and the
current state of thread support does not support writing portable
applications which do not have to incorporate system-specific
knowledge, thus negating the positive effects intended to be achieved
through std::system_error. Defering the decision to implement separate
error handling machinery until the time when it is widely (and
consistently) used by the C++ Standard Library is a conservative
choice that later generations of C++ programmers may appreciate.
2. Existing POSIX error codes and categories served as an inspiration
for much of the new error handling machinery. Because of this, members
of the POSIX C++ working group were keen to review this proposal and
have been working to resolve outstanding issues. However, there has
been persistent concern from the POSIX C++ group about aspects of the
draft specification. These concerns include, but may not be limited
to: excessive undefined and implementation-defined behavior limiting
utility, lack of integration with localized error messages supported
in the POSIX "C" interface, and namespace collision with future
standardization efforts of the POSIX C++ working group. Because of
these concerns, the POSIX C++ working group has submitted a formal
motion to the ISO C++ LWG to consider deferring this work until the
TR2 time frame.
Proposed Wording.
Change 17.4.1.2 Headers [headers], Table 13: C++ Library Headers as follows:
Remove <system_error>
Change 17.4.4.9 Value of error codes [value.error.codes] by removing
it entirely.
Change Chapter 19 Diagnostics library [diagnostics] Table 27:
Diagnostics Library Summary as follows:
Remove 19.4 System error support <system_error>
Change 19.4 System error support [syserr] by removing it entirely.
Change 20.5 Function objects [function.objects] paragraph 2, Header
<functional> synopsis, the Hash function specializations part by
removing the specialization:
template <> struct hash<std::error_code>;
Change 20.5.16 Class template hash [unord.hash] paragraph 1 as follows:
The unordered associative containers defined in clause 23.4 use
specializations of hash as the default hash function. This class
template is only required to be instantiable for integer types
(3.9.1), floating point types (3.9.1), pointer types (8.3.1), and
std::string, std::u16string, std::u32string, std::wstring, and
std::thread::id.
Change 30.1.2 Exceptions [thread.req.exception] as follows:
Adjust paragraph 1 to read:
Implementations of functions described in this clause are permitted
to call operating system or other low-level applications program
interfaces (API's). Some functions described in this clause are
specified to throw exceptions of type runtime_error (19.1.6). Such
exceptions shall be thrown if such a call results in an error that
prevents the library function from satisfying its postconditions or
from returning a meaningful value.
Remove paragraph 2 entirely, ie:
The error_category (19.4.1.1) of the error_code reported by such an
exception's code() member function is implementation-defined. [
Note: The category is typically system_category (19.4.1.1) since these
error codes usually originate from the underlying operating system
application program interface (API). -end note ]
Change 30.2.1.2 thread constructors [thread.thread.constr] paragraph 9
as follows:
Throws: std::runtime_error or std::bad_alloc if unable to start the new thread.
Change 30.2.1.5 thread members [thread.thread.member] paragraph 8 as follows:
Throws: std::runtime_error when the postconditions cannot be achieved.
Change 30.2.1.5 thread members [thread.thread.member] paragraph 12 as follows:
Throws: std::runtime_error when the effects or postconditions cannot
be achieved.
Change 30.3.1 Mutex requirements [thread.mutex.requirements] paragraph
3 as follows:
A Mutex type shall be DefaultConstructible and Destructible. If
initialization of an object of a Mutex type fails, 3 an exception of
type std::runtime_error shall be thrown. A Mutex type shall not be
copyable nor movable.
Change 30.3.1 Mutex requirements [thread.mutex.requirements] paragraph
10 as follows:
Throws: std::runtime_error when the effects or postcondition cannot be achieved.
Change 30.3.1.2 Class recursive_mutex [thread.mutex.recursive]
paragraph 3 as follows:
A thread that owns a recursive_mutex object may acquire additional
levels of ownership by calling lock() or try_lock() on that
object. It is unspecified how many levels of ownership may be acquired
by a single thread. If a thread has already acquired the maximum level
of ownership for a recursive_mutex object, additional calls to
try_lock() shall fail, and additional calls to lock() shall throw an
exception of type std::runtime_error. A thread shall call unlock() once
for each level of ownership acquired by calls to lock() and
try_lock(). Only when all levels of ownership have been released may
ownership be acquired by another thread.
Change 30.3.2.2 Class recursive_timed_mutex
[thread.timedmutex.recursive] paragraph 3 as follows:
A thread that owns a recursive_timed_mutex object may acquire
additional levels of ownership by calling lock(), try_lock() or
timed_lock() on that object. It is unspecified how many levels of
ownership may be acquired by a single thread. If a thread has already
acquired the maximum level of ownership for a recursive_timed_mutex
object, additional calls to try_lock() or timed_lock() shall fail, and
additional calls to lock() shall throw an exception of type
std::runtime_error. A thread shall call unlock() once for each level of
ownership acquired by calls to lock(), try_lock() and
timed_lock(). Only when all levels of ownership have been released may
ownership of the object be acquired by another thread.
Change 30.3.5.2 Function call_once [thread.once.callonce] paragraph 4
as follows:
Throws: std::runtime_error when the effects cannot be achieved, or any
exception thrown by func.
Change 30.4.1 Class condition_variable [thread.condition.condvar]
paragraph 11 as follows:
Throws: std::runtime_error when the effects or postcondition cannot be achieved.
Change 30.4.1 Class condition_variable [thread.condition.condvar]
paragraph 17 as follows:
Throws: std::runtime_error when the returned value, effects, or
postcondition cannot be achieved.
Change 30.4.2 Class condition_variable_any
[thread.condition.condvarany] paragraph 10 to:
Throws: std::runtime_error when the effects or postcondition cannot be achieved.
Change 30.4.2 Class condition_variable_any
[thread.condition.condvarany] paragraph 15 to:
Throws: std::runtime_error when the returned value, effects, or
postcondition cannot be achieved.