CppCon 2017

Amongst the loud fanfare of C++11 arrived this quiet little gem of ＜system_error＞, with std::error_code and std::error_condition born from the heart of boost::asio. With Committee input they evolved for inclusion into the C++11 Standard, providing consistent and extensible ways for applications to expose platform-specific error-codes, platform-independent error-conditions, and rely upon an open-ended design that permits future extensibility for message reporting; and even internationalization of logs and user-facing events and conditions.

More than half a decade later, we most unhappily find that the motivation and intended use model for std::error_code and std::error_condition are still not well understood; even in circles eagerly embracing features and idioms encouraged by the latest C++ Standard revisions. This may be somewhat expected, as all things “error” tend to permeate system-wide design-decisions and influence the processing metaphor; how algorithms compose conditional success-or-failure branching; and create consistency challenges across APIs (both internally, and for interoperation with third-party libraries).

We discuss the features and design of ＜system_error＞ and its intended use; make recommendations regarding API design; and propose possible extension mechanisms for module-specific concerns, instance-specific messages (with embedded value-reporting), and internationalization.