This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of New status.

### 3019. Presentation of "program defined classes derived from `error_category`" [syserr.errcat.derived] unclear and contains mistakes

Section: 19.5.3.4 [syserr.errcat.derived] Status: New Submitter: Thomas Köppe Opened: 2017-09-20 Last modified: 2017-11-09

Priority: 3

View all issues with New status.

Discussion:

The presentation of section [syserr.errcat.derived] is currently somewhat problematic:

- It is not clear why this section exists and what it is specifying. Presumably, it is the subject of the phrase "in this subclause" of the sibling section [syserr.errcat.overview], but that's confusing (because this would require the interpretation of "this subclause" as the containing superclause). It would be an improvement to say "shall behave as specified in [syserr.errcat.derived]" in the introduction.

- The current wording of [syserr.errcat.derived] requires that derived classes keep the `name` member function pure-virtual, making it impossible to have non-abstract derived classes. This appears to be an editorial error. Surely `name` should just not be required to be pure-virtual.

- There seems to be no requirement concerning the `message` virtual member function.

- We should use `override` rather than `virtual`.

- I would welcome a short, introductory paragraph in [syserr.errcat.derived] that states (non-redundantly) that the following are requirements on users' derived classes.

Partial wording proposal:

1. In 19.5.3.1 [syserr.errcat.overview] p1, change:

   > -1- The class `error_category` serves as a base class for types used to identify the source and encoding of a particular category of error code. Classes may be derived from `error_category` to support categories of errors in addition to those defined in this International Standard. Such classes shall behave as specified in this subclause 19.5.3.4 [syserr.errcat.derived]. [Note: `error_category` objects are passed by reference, and two such objects are equal if they have the same address. This means that applications using custom `error_category` types should create a single object of each such type. — end note]

2. In 19.5.3.4 [syserr.errcat.derived], change:

   >     virtual const char* name() const noexcept override  = 0;

   > > -1- Returns: A string naming the error category.

   >     virtual error_condition default_error_condition(int ev) const noexcept override;

   > > -2- Returns: An object of type `error_condition` that corresponds to `ev`.

   >     virtual bool equivalent(int code, const error_condition& condition) const noexcept override;

   > > -3- Returns: `true` if, for the category of error represented by `*this`, `code` is considered equivalent to `condition`; otherwise, `false`.

   >     virtual bool equivalent(const error_code& code, int condition) const noexcept override;

   > > -4- Returns: `true` if, for the category of error represented by `*this`, `code` is considered equivalent to condition; otherwise, `false`.

[2017-11 Albuquerque Wednesday night issues processing]

Priority set to 3.

Jonathan to talk to Chris K and Walter about writing a paper describing the use of `error_code`, `error_condition` and defining your own.

Proposed resolution: