On Mon, Jan 9, 2023 at 4:39 PM Jason McKesson via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> A good proposal needs to start with motivation.


The conversation we're having right now takes more time and effort than
copy-pasting the following paragraph into Section 17.9.6 of C++26:

[ - - START COPY-PASTE - - ]
std::type_info const &current_exception_typeid(void) noexcept;
Returns: A reference to a 'type_info' object that refers to the
currently handled
exception (14.4), or simply 'typeid(void)' (7.6.1.7) if no exception
is being handled.
The return values of two successive calls to
'current_exception_typeid' refer to the
same 'type_info' object.
[ - - END COPY-PASTE - - ]

Furthermore, compiler vendors haven't got much work to do. The GNU guys can
copy-paste the following snippet into their text file named 'exception':

    inline type_info const &current_exception_typeid(void) noexcept
    {
        type_info const *const p = abi::__cxa_current_exception_type();
        if ( p ) return *p;
        return typeid(void);
    }

And here it is for Microsoft:

  inline type_info const &current_exception_typeid(void) noexcept
  {
        _ThrowInfo const *const p1 = static_cast<_ThrowInfo const*>(
             static_cast<void const*>(
             ExceptionPointers->ExceptionRecord->ExceptionInformation[2u]));

        if ( nullptr == p1 ) return typeid(void);

        type_info const *const p2 =
                p1->pCatchableTypeArray->arrayOfCatchableTypes[0u];

        if ( nullptr == p2 ) return typeid(void);

        return *p2;
}

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.


> something that the current language cannot do, as well as explain why
> it is important to be able to do that thing.


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.


> Your proposal does not. It says what you can't do, but it never says
> why doing that would be useful. It merely assumes that everyone agrees
> that we ought to be able to do 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.
If it meant rewriting entire pages of the Standard and getting compiler vendors
to spend four months implementing a new feature, then yeah fair enough I'd say
that mere group consensus isn't enough. But for this particular feature, I think
it's enough for us to be thinking "We ought to have this".


> 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?


Personally I never throw anything that doesn't inherit from std::exception,
so this isn't really for me. But I have to interact with shared
libraries provided
by other people though, and that's why I want the Committee to choose
one of the following for C++26:
Choice 1: Deprecate the throwing of non-std::exception's.
Choice 2: Provide RTTI inside catch(...)

And yeah I'd probably print debugging information if an unhandled exception
propagated all the way up to a 'catch(...)' body inside 'main', or perhaps send
some error info out over a HTTP socket I have going.


> 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*.


std::exception has a virtual destructor, which means that it's a polymorphic
type, which means that when you apply 'typeid' to it, you don't get the
type_info for std::exception but rather you get the type_info for what was
thrown -- which is *exactly* what I'm looking for.