Hi,

On 10 January 2023 00:14:19 GMT, Thiago Macieira via Std-Proposals <std-proposals_at_[hidden]> wrote:
>On Monday, 9 January 2023 08:39:20 PST Jason McKesson via Std-Proposals wrote:
>> Is this for printing out some debugging information? Are you going to
>> start comparing it to other `type_info`s and doing a bunch of casting
>> to figure out what it could be (which would be exceedingly pointless)?
>> What is the point of getting this information if there's nothing you
>> can really do about it?
>
>I should point out that "comparing type_info to know class typeids" is exactly
>what catch will do for you and more efficiently. The only reason you'd write
>manual code is if the list of types to be matched against isn't known at
>compile-time but instead is itself runtime-populated.
>
>> As for your suggestion that we shouldn't be able to throw anything
>> that isn't derived from `std::exception`, again I ask: why? What would
>> that do which you can't do otherwise? The only functionality of
>> `std::exception` is that it carries a message via a `char const*`. But
>> even that could just be an empty string, so you are guaranteed
>> precisely *nothing*.
>
>We can't remove that ability because code exists that uses that.
>
>It's bad practice though. And since it should be avoided, the proposal needs
>to explain why you're in fact adding functionality for its benefit. If the
>thrown type derives from std::exception, you can catch by std::exception and
>run typeid on the type you got.

One use case I recently looked at is when you replace the terminate handler, you might want to be able to log the exception type of any type of exception, if terminate is called due to that. This is done by some of the default handlers, but they have to be implemented in a non-standard way to get to the name of the type.

Cheers,
Lénárd