Date: Tue, 10 Jan 2023 09:17:34 +0100
> One does not need to be greatly motivated if one does not need to
> expend much effort. I mean the above 40 lines are everything
> everyone needs.
So the standard should be a dumping ground for "clever ideas" that
have not been fully thought through? I think the standard should set
the bar higher than that.
> I think community consensus is enough given how easy it is to
> copy-paste the aforementioned paragraph into section 17.9.6 of
> the Standard.
What community consensus? Before you can get consensus you need to
convince people that this is a good idea, and how are you going to do
that without writing a motivation?
> Either C++26 should deprecate the throwing of objects not derived
> from 'std::exception', or it should provide a means of getting
> the RTTI inside 'catch(...)'. One or the other. It doesn't make
> sense to do neither.
You say it doesn't make sense but WHY doesn't it make sense?
I have never needed RTTI inside a catch block.
I have, on a few rare occasions, thrown types (enums) that were not
derived from std::exceptions.
So to me it is your two options that doesn't make sense.
> expend much effort. I mean the above 40 lines are everything
> everyone needs.
So the standard should be a dumping ground for "clever ideas" that
have not been fully thought through? I think the standard should set
the bar higher than that.
> I think community consensus is enough given how easy it is to
> copy-paste the aforementioned paragraph into section 17.9.6 of
> the Standard.
What community consensus? Before you can get consensus you need to
convince people that this is a good idea, and how are you going to do
that without writing a motivation?
> Either C++26 should deprecate the throwing of objects not derived
> from 'std::exception', or it should provide a means of getting
> the RTTI inside 'catch(...)'. One or the other. It doesn't make
> sense to do neither.
You say it doesn't make sense but WHY doesn't it make sense?
I have never needed RTTI inside a catch block.
I have, on a few rare occasions, thrown types (enums) that were not
derived from std::exceptions.
So to me it is your two options that doesn't make sense.
Received on 2023-01-10 08:17:47