No-value policies

In the previous section we have seen that it would be useful if calling member function .value() on object of type outcome<T> that did not contain a value, would cause an exception to be thrown according to some user-defined policy.

Let us consider result<T> first. It is an alias to basic_result<T, E, NoValuePolicy> , where E is the type storing error information and defaulted to std::error_code/boost::system::error_code, and NoValuePolicy is a no-value policy defaulted to default_policy<T, EC, EP> .

The semantics of basic_result::value() are:

1. Calls NoValuePolicy::wide_value_check(*this).
2. Return a reference to the contained value. If no value is actually stored, your program has entered undefined behaviour.

Thus, the semantics of function .value() depend on the no-value policy. The default policy (policy::default_policy<T, EC, void>) for EC of type std::error_code¹ does the following:

• If r.has_value() == false throws exception std::system_error{r.error()},
• otherwise no effect.

When designing your own success-or-failure type using templates basic_result<> or basic_outcome<> you have to decide what no-value policy you want to use. Either create your own, or use one of the predefined policies.

You can also use one of the two other predefined aliases for basic_result<>:

• unchecked<T, E = varies> : it uses policy all_narrow , where any observation of a missing value or error is undefined behavior;
• checked<T, E = varies> : it uses policy throw_bad_result_access<EC> , where any observation of a missing value or error throws bad_result_access_with<EC> or bad_result_access respectively.