# Approximate map between error code designs

Much of the design of Boost.System (which went on to become `<system_error>`) has been retained in proposed `<system_error2>`, so an approximate map between `<system_error2>` and `<system_error>` and Boost.System can be given:

C++ 17 `<system_error>` | Boost.System | Proposed `<system_error2>`
--- | --- | ---
`std::errc` | `boost::system::errc` | `experimental::errc` (almost identical)
`std::error_category` | `boost::system::error_category` | `experimental::status_code_domain`
`std::generic_category` | `boost::system::generic_category` | `experimental::generic_code_domain`

`std::system_category`

`boost::system::system_category`

One of:

- `experimental::posix_code_domain` (POSIX systems)

- `experimental::win32_code_domain` (Microsoft Windows)

- `experimental::nt_code_domain` (Microsoft Windows)

Note that there are more precanned code categories though they require additional header inclusions: `com_code`, `getaddrinfo_code`.

`std::error_condition` | `boost::system::error_condition` | No equivalent (deliberately removed as hindsight proved it to be a design mistake leading to much confusing and hard to audit for correctness code)

`std::error_code`

`boost::system::error_code`

One of:

- `experimental::status_code<DomainType>`

- `const experimental::status_code<void> &`

- `experimental::status_code<erased<intptr_t>>` (aliased to `experimental::system_code`)

- `experimental::errored_status_code<DomainType>`

- `const experimental::errored_status_code<void> &`

- `experimental::errored_status_code<erased<intptr_t>>` (aliased to `experimental::error`)

The difference between status codes and errored status codes is that the latter are guaranteed to refer to a failure, whereas the former may refer to a success (including warnings and informationals).

`std::system_error`

`boost::system::system_error`

One of:

- `const experimental::status_error<void> &`

- `experimental::status_error<DomainType>`

As is obvious from the above, in `<system_error2>` one must be much more specific and accurate with respect to intent and specification and desired semantics than with `<system_error>`. Much ambiguity and incorrectness which flies silently in `<system_error>` will refuse to compile in `<system_error2>`.

Last revised: December 16, 2020 at 14:14:42 UTC