Until something like this is supported, I'm using this approach -
https://github.com/eyalz800/zpp_throwing

On Sat, Apr 2, 2022, 22:15 Ivan Matek via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> You might find this interesting:
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0779r0.pdf
> Obviously proposal went nowhere, but IDK why.
>
> On Sun, Mar 27, 2022 at 8:57 PM Cesar Torres via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
>> There is an error handling pattern that appears repeatedly in many C++
>> codebases:
>>
>> (1)
>> ​auto maybe_result_or_error = a_function_that_may_fail();
>> if (maybe_result_or_error.has_error())
>> return maybe_result_or_error.error();
>> auto result = maybe_result_or_error.result();
>>
>> Here, we call a function that may fail, in which case we get an object
>> explaining or signaling the error.
>> We check if the result has an error, in which case we don't want to
>> continue executing the current function, and return the error, propagating
>> it.
>>
>> Sometimes, it also looks like:
>> (2.1)
>> auto maybe_error = a_function_that_may_fail();
>> if (maybe_error.has_error())
>> return maybe.error();
>> OR
>> (2.2)
>> auto maybe_error = a_function_that_may_fail();
>> if (maybe_error.has_error())
>> return;
>>
>>
>> Here, the function we call doesn't return anything unless it fails, in
>> which case we get an object signaling the error.
>> As in the first case, in many cases the programmer will want the function
>> to return because we
>> didn't get what we wanted from that function (be it a connected socket,
>> an open file, a memory allocation, etc).
>> We return the error, propagating it.
>>
>> In other codebases, it might look like this:
>>
>> (3)
>> auto* maybe_ptr = a_function_that_may_return_null();
>> if (maybe_ptr == nullptr)
>> return;
>> auto result = *maybe_ptr;
>>
>> There is a common pattern here. We get a return value from a function,
>> check if it's valid,
>> in which case we unwrap that result, or if it's invalid, in which case we
>> do something, often returning the error to propagate it.
>>
>> I propose a new syntax feature:
>>
>> auto result = try a_function_that_may_fail(); // for examples (1) and (3)
>> AND
>> try a_function_that_may_fail(); // for examples (2.1) and (2.2)
>>
>> This translates internally to the respective examples, and serves the
>> purpose of simplifying a common pattern that, just
>> like for loops with iterators, is very common to see in projects that do
>> not make use of exceptions. It moves boilerplate
>> away from the code in a zero-cost way.
>> It should return the error value if the return value of the function it
>> appears in is not void and is implicitly constructible from the
>> error type. The approach to implementing this, in order to make it a soft
>> feature like structured-binding, could be with
>> special member function names like has_error(), result() and error(),
>> akin to how structured-binding uses get() for tuples (e).
>> Types like std::expected have these methods, and could be used with this
>> new syntax sugar.
>>
>> A macro version is already in use in some projects (see references (a)
>> and (b) for uses and (c) for the macro implementation),
>> or is even built-in in languages like Rust (d).
>>
>>
>> I look forward to your feedback,
>> Cesar Torres.
>>
>>
>> References:
>>
>> a.
>> https://github.com/SerenityOS/serenity/blob/master/Documentation/Patterns.md#try-error-handling
>> b.
>> https://github.com/SerenityOS/serenity/blob/f7f14d52e0beeb61b133e556e3e5b841e570d364/Userland/Applications/ImageViewer/main.cpp#L42
>> c.
>> https://github.com/SerenityOS/serenity/blob/f7f14d52e0beeb61b133e556e3e5b841e570d364/AK/Try.h
>> d.
>> https://doc.rust-lang.org/book/ch09-02-recoverable-errors-with-result.html#a-shortcut-for-propagating-errors-the--operator
>> e. https://en.cppreference.com/w/cpp/language/structured_binding
>>
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>