On Tue, Jun 18, 2024 at 1:02 PM Yexuan Xiao via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> Hello everyone,
> I’ve recently come up with a new idea and I’m looking for some feedback
> and opinions.
>
> Currently, when using exceptions derived from std::exception and the
> status_code from P1028, it’s common to need to convert error values into
> exception objects. [...] C++ currently lacks a best practice for
> converting error codes into exception objects.
>

The two example approaches you gave were:
    std::error_code ec;
    throw std::system_error(ec); // (1)
    my::throw_system_error(ec); // (2); calls `void
throw_system_error(std::error_code ec) { throw std::system_error(ec); }`

These both seem totally fine approaches. Neither of them is too verbose,
and they clearly show the reader what's happening.
In fact, (2) is just (1) with the offending code factored out into a
function; that's a good kind of refactoring that we want to continue to
permit.

Therefore, I propose adding user-defined operator throw overload to
> implement automatic conversion from error codes to exception objects.
>

But why, though? I don't see that you've presented any problem that needs
solving.
In fact, it seems to me that you're taking a non-problem (that if you want
to convert X to Y and then throw Y, you write that) and making it *into* a
problem (that it becomes impossible to throw X from generic code because
there's no way to ensure that the author of X hasn't done something dumb in
their `operator throw` implementation).

This idea is inspired by the existing operator co_await in C++, which
> facilitates the construction of awaiters for us.
>

My understanding is that `operator co_await` solves an actual problem
(although off the top of my head I don't know what it is).
Its existence should not be taken as license to invent an `operator foo`
for every named operator in C++. We don't need `operator throw`, `operator
sizeof`, etc. (In hindsight, C++98's class-specific `operator new` and
`operator delete` were mistakes too.)


> Additionally, F. v.S. pointed out that this design has an extra side
> effect: if operator throw is overloaded as a member function, then the
> class can never be the actual type of an exception. Based on this, by
> avoiding defining operator throw(), or by adding =delete to it, can prevent
> objects of that class from being thrown as exception objects.
>

That's a bug, not a feature.
There is no idea here worth pursuing.

–Arthur