On Mon, Sep 14, 2020 at 3:21 PM Dmitry Dmitry via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>>>
>>>
>> However, what you want is already possible in Standard C++:
>>
>> std::optional<std::string> FindUsersCity() {
>> try {
>> std::optional<ContactsServer> contacts = GetOrOpenContactsServerConnection();
>> std::optional<UserId> uid = contacts.value().GetUserId(); // throw bad_optional_access on empty
>> std::optional<GeoServer> geo = GetOrOpenGeoServerConnection();
>> std::optional<Location> uloc = geo.value().GetLocation(uid.value()); // throw bad_optional_access on empty
>> return uloc.value().GetCityName();
>> } catch (const std::bad_optional_access&) {
>> return std::nullopt;
>> }
>> }
>>
>
> If you want the same level of flexibility as with returns (and you usually want, because sometimes you need to be more specific and capture some context/explanation),

Then the functions detecting the error situation should be the ones
throwing the error, rather than relying on a generic
`bad_optional_access` error.

If those functions emitted an `expected<T, error>`, then the `error`
would contain adequate context information. And therefore, if an
exception gets thrown, the catcher will at least have the error code
or whatever is needed to provide context.