I reply in series below to Sebastian, Jan, Matthew and Arthur.


On Fri, Mar 1, 2024 at 12:46 PM, Sebastian Wittmeier wrote:
>
> It probably is also related to https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p2927r1.html
> (Inspecting exception_ptr / Observing exceptions stored in exception_ptr) by Gor Nishanov and Arthur
> O'Dwyer, which introduces try_cast.


That paper is to do with exceptions but it isn't specifically about
getting access to the type_info of the exception object referred by an
exception_ptr.


On Fri, Mar 1, 2024 at 12:50 PM, Jan Schultke wrote:
>
> It's also unclear why you would return "typeid(void)" when given a
> null pointer as an input. Shouldn't that throw an exception or be
> undefined behavior?


If you have an object of type "std::any" and if you call the "type()"
method on it when it hasn't got a value, it returns "typeid(void)". I
was trying to keep consistency with the rest of the standard library.


> Furthermore, wouldn't it make more sense to specify exception_ptr in
> more detail? Perhaps we could get away with specifying it as a class
> type that has a "type_info()" member function. That seems more
> reasonable than a separate free function, if this mechanic is 100%
> tied to exception_ptr anyway.


I'd be in favour of this so long as it's not an ABI break. But also it
would mean that "exception_ptr" can't be something as simple as a
typedef for "shared_ptr<void>".


> Personally, I dislike the name "typeid_except". It's not obvious what
> it does and you use it so rarely that abbreviating the name is
> pointless. Perhaps "exception_typeid()" would be better.


I want it to look like the "typeid" operator, but for use with exception_ptr's.


On Fri, Mar 1, 2024 at 12:58 PM, Matthew Taylor wrote:
>
> Also, while I'm not against the core idea I'm not entirely convinced by your motivation.
> Your sole example is getting RTTI from an exception thrown across a shared library
> boundary; when there may not be a typeinfo for an arbitrary foreign exception in the first place.


But _if_ there is typeinfo available then I want to be able to see it.
If not then just give typeid(void).


On Fri, Mar 1, 2024 at 4:41 PM, Arthur O'Dwyer wrote:
>
> - Remove the default argument.


I thought it would be convenient.


> - Pass the exception_ptr by const&, for efficiency: we are only reading it, not "sinking" it. (Compare P2927.)


I actually passed it by value for the sake of efficiency (i.e. one
less level of indirection) but I was forgetting that we're dealing
with something similar to a shared_ptr, and so yes it's better to take
it by L-value const reference.


> - What is the motivation for this facility? It doesn't seem useful to get a typeid, because you can't do anything with a typeid.
> You can't even compare the typeid to anything to learn e.g. whether the exception IS-A std::exception. This doesn't seem
> useful at all, without further major additions to std::type_info. If you think it is useful somehow, you should put that in the
> paper; and if you don't think it's useful, then you shouldn't waste our (or anyone's) time with it.


Let's say I write a program, something big along the lines of Autodesk
Maya for making 3D models, and let's say I allow the user to load
3rd-party plugins at runtime. So I use 'dlopen' at runtime to load one
of these plugins, and I don't know until runtime that the plugin is
called 'FieryShadow'. An exception is thrown from somewhere, and I can
at least see the type's name:

    char const *const plugin_name = "FieryShadow"; // plugin name
not known until runtime

    catch(...)
    {
        type_info const &ti = typeid_except();
        if ( strstr( ti.name(), plugin_name ) ) throw
std::runtime_error("exception thrown from active plugin");
    }

When it comes to logging exceptions when debugging (or even in release
builds), I would like if we could get a raw pointer to the exception
object along with the size of the exception object, so that we can
print its hex bytes, something like the following GodBolt:

    https://godbolt.org/z/348aT9Tf7

which prints out:

    Type of exception object: 5Dummy
    Size of exception object: 32
     Hex: 46726f6773313233000000000000000000000000000000000000000000000000
    ASCII: Frogs123