Assertions are Boolean expressions that are expected to be true at a given point in the code. The assert macro of <cassert> is defined similar to this:

If an assertion fails, a diagnostic message is written to the standard error output, and std::abort() is called, which terminates the application without performing any cleanup. While debugging an application, certain IDEs give you the option to continue the execution if an assertion fails. Common practice is to use assertions as a debugging aid and to define NDEBUG when building a release build of your application, turning asserts into no-operations.

Assertions are generally used to check invariants, such as loop invariants, or function pre- and postconditions. One example is parameter validation:

A possible output of this program is

std::exception, defined in <exception>, is not intended to be thrown itself but instead serves as a base class for all exceptions defined by the Standard Library and can serve as a base class for your own. Figure 8-1 outlines all standard exceptions.

An exception can be copied and offers a what() method that returns a string representation of the error. This function is virtual and should be overridden. The return type is const char*, but the character encoding is not specified (Unicode strings encoded as UTF-8 could be used, for instance; see Chapter 6).

The exceptions defined in <stdexcept> are the only standard exceptions that are intended to be thrown by application code. As a rule, logic_errors represent avoidable errors in the program’s logic, whereas runtime_errors are caused by less predictable events beyond the scope of the program. logic_error, runtime_error, and most of their subclasses (except system_errors and future_error, which require an error code, as discussed later) must be passed a std::string or const char* pointer upon construction, which is returned by what() afterward. There is thus no need to further override what().

The <exception> header provides std::exception_ptr, an unspecified pointer-like type, used to store and transfer caught exceptions even without knowing the concrete exception type. An exception_ptr can point to a value of any type, not just an std::exception. It can point to a custom exception class, an integer, a string, and so on. Any pointed-to value stays valid while there is at least one exception_ptr still referring to it (that is, a reference-counted smart pointer may be used to implement exception_ptr).

Once created, exception_ptrs can be copied, compared, and in particular assigned and compared with nullptr. This makes them useful to store and move exceptions around and to test later whether an exception has occurred. For this, an exception_ptr is also convertible to a Boolean: true if it points to an exception, false if it is a null pointer. Default constructed instances are equivalent to nullptr.

Exception pointers can be used, for example, to transfer exceptions from a worker thread to the main thread (note that this is essentially what the utilities of <future> discussed in the previous chapter implicitly do for you, as well):

The <exception> header also offers facilities to work with nested exceptions. They allow you to wrap a caught exception in another one: for instance, to augment it with extra context information or to convert it to a more suitable exception for your application. std::nested_exception is a copyable mixin¹ class whose default constructor captures current_exception() and stores it. This nested exception can be retrieved as an exception_ptr with nested_ptr(), or by using rethrow_nested(), which rethrows it. Take care, though: std::terminate() is called when rethrow_nested() is called without any stored exception. It is therefore generally recommended that you not use nested_exception directly, but use these helper methods instead:

The following example demonstrates nested exceptions:

The output of this piece of code is as follows:

Errors from the operating system or other low-level APIs are called system errors. These are handled by classes and functions defined in the <system_error> header:

In addition to a numeric value, both error_code and error_condition objects hold a reference to their error_category. Within one category, a number is unique, but the same number may be used by different categories.

All this may seem fairly complicated, but the main uses of these errors remain straightforward. To compare a given error code, such as that from a caught system_error exception, with either an error condition or a code, the == and != operators can be used. For instance:

The <cerrno> header defines errno, a macro that expands to a value equivalent to int&. Functions can set the value of errno to a specific error value to signal an error. A separate errno is provided per thread of execution. Setting errno is very common for functions from the C headers. The C++ libraries mostly throw exceptions upon failure, although some set errno as well (std::string-to-numeric conversions, for example). Table 8-2 lists the macros with default POSIX error numbers defined by <cerrno>.

If you want to use errno to detect errors in functions that use errno to report errors, then you have to make sure to set errno to 0 before calling the function, as is done in this example (needs <cmath>)²:

The output depends on your platform, but it can be something like the following:

For completeness, we show two alternative ways of reporting an error string for the current errno. They use, respectively, strerror() from <cstring> (take care: this function is not thread-safe!) and std::perror() from <cstdio>. The following two lines print a message similar to the earlier code: