Auto-throwing filesystem_error

Something not mentioned at all until now (and properly described in the next section, Default actions) is that Outcome can be programmed take various actions when the user tries to observe .value() when there is no value, and so on for the other possible state observations. Seeing as we are replacing the throwing overload of copy_file() in the Filesystem TS with a result returning edition instead, it would make sense if an attempt to observe the value of an unsuccessful fs_result threw the exact same filesystem_error as the Filesystem TS does. »

Inspecting outcome<T, EC, EP>

Continuing with the previous example, in Layer3 we have function z which again reports failures via exceptions. It will call function h from Layer2_old which returns outcome<int> (which may store an int or a std::error_code or a std::exception_ptr). The goal is to unpack it to either the successful return value int or to throw an appropriate exception: if we are storing an std::exception_ptr, just rethrow it. If we are storing a std::error_code throw it as std::system_error, which is designed to store std::error_code’s: »

Inspecting result<T, EC>

Suppose we will be writing a function print_half that takes a std::string representing an integer and prints half the integer: outcome::result<void> print_half(const std::string& text); View this code on Github The type result<void> means that there is no value to be returned upon success, but that the operation might still fail, and we may be interested in inspecting the cause of the failure. The class template result<> is declared with the attribute [[nodiscard]], which means the compiler will warn you if you forget to inspect the returned object (in C++ 17 or later). »