On Tue, Jan 10, 2023 at 9:00 AM Thiago Macieira via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> On Tuesday, 10 January 2023 00:38:42 PST Ville Voutilainen wrote:
> > On Tue, 10 Jan 2023 at 02:23, Thiago Macieira via Std-Proposals
> >
> > <std-proposals_at_[hidden]> wrote:
> > > As I said, throwing types not derived from std::exception should be
> > > discouraged by recommendation.
> >
> > I'm not so convinced of that. Some applications have been designed
> > with the plausible rationale that
> > their domain-specific exceptions are separate from standard library
> > exceptions, and are to be treated as such.
>
> Which is why we can't deprecate. There are some uses, however much I may
> disagree with them. So let them exist.
>
> But we don't need to encourage them.

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.

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.

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.