On Wednesday, March 6, 2024, Tom Honermann wrote:

> On 3/6/24 3:07 AM, Frederick Virchanza Gotham wrote:
>
> For the form that returns a std::type_info reference for the currently
> handled exception, I prefer current_exception_typeid() for consistency
> with current_exception() and the typeid operator (assuming this form is
> needed at all).
>


I don't agree with you here however it would be a small compromise to make,
if more people would prefer 'current_exception_typeid'. I'm not gonna get
caught up on what English words we use -- so long as we can use the feature.


For the form that returns a std::type_info reference from a
> std::exception_ptr *E*, I prefer the addition of a type_info() member
> function to enable *E*.type_info() assuming that this is implementable on
> all platforms without an ABI break ([propagation]p6
> <http://eel.is/c++draft/propagation#6> contains a note that states "An
> implementation can use a reference-counted smart pointer as exception_ptr"
> which suggests to me that a generic smart pointer can be used subject to
> the implicit conversion limitations).
>


Yeah I think it might be an idea to add a few non-static non-virtual
methods to 'exception_ptr', such as to get the 'type_info', or to get a
pointer to the bytes of the exception object.

For the time being though, I want to keep this proposal very simple. It
won't be the end of the world if we end up with a little redundancy in
C++29 whereby we have a choice of using either 'std::typeid_except' or
'std::exception_ptr::type'.



> If that isn't an option for some implementations, then I prefer
> get_exception_type_info() for consistency with rethrow_exception().
>
> If the latter form is provided, then I don't see a need for the former
> form. I don't see compelling motivation to be able to query the type in the
> forced unwinding scenario in which current_exception() returns a null
> std::exception_ptr.
>


I want to be comprehensive here and cover all bases. The last thing I want
is to receive an email in 2031 from some guy writing a compiler for an
Arduino microcontroller asking me why I didn't push harder for the
parameterless version. But even today in 2024, we have scenarios where
'current_exception()' returns a nullptr even though there is 'type_info'
available. If a person is logging every exception that is thrown, i.e.
logging the 'type_info' and also possibly the 'what()' of what was thrown,
then maybe they also want to log forced unwinds too, and to have something
descriptive like "abi::__forced_unwind" instead of just 'typeid(void)'.

I think we really should have a parameterless version of the function.
Personally I would give both functions the same name, but if others want to
give them different names then I'm easy.