On Tuesday, 10 January 2023 06:40:35 PST Jason McKesson via Std-Proposals
wrote:
> I disagree with this.
>
> `std::exception` is not a good type. The only actual functionality it
> provides is a virtual interface for getting a `char const*`. Which
> then locks any user into using that *specific* interface for
> retrieving a description of the error. If I want to get the string as
> a `string_view` or `span<char const*>` so that I can embed NUL
> characters, I'm out of luck. Or better yet, maybe I want to use a
> `char8_t const*` so everyone knows its UTF-8 encoded.

A text description has no business including NUL.

In any case, that's what happens when things get designed in the late 80s and
early 90s. Today, a green-field design would indeed use string_view.

And std::string_view is UTF-8 if you put UTF-8 in.

> I see no reason why we should in any way discourage library writers
> from using their own exception base class that provides the base
> functionality appropriate to their library.

They're welcome to do that inside their own libraries. C++ allows it. Someone
else in this thread said they're throwing enums. It's not for performance they
do it, though.

But if you want users to catch exceptions, PLEASE derive from std::exception.
You can create your own base that adds stuff and you can even not have a
meaningful what().

> The problem as outlined by the OP is not *really* about a function
> that doesn't throw a `std::exception`-derived exception. It's about
> when a library, through either bad documentation or bad programming,
> throws an exception of a type that it never stated would be thrown.

Hence the catch-all
  catch (std::exception &e)

and hence why the recommendation should be that all exception types derive
from std::exception.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel DCAI Cloud Engineering