On Sat, Mar 2, 2024 at 7:36 PM Frederick Virchanza Gotham via Std-Proposals
<std-proposals_at_[hidden]> wrote:

> On Fri, Mar 1, 2024 at 12:50 PM, Jan Schultke wrote:
>
> 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>".
>

Yes, FWIW, P2927 shied away from trying to add member functions to
exception_ptr, precisely because we figured there must be a reason it's not
defined as a class type today. Off the top of my head I'm not sure if it's
allowed to be a type alias for `shared_ptr<void>`, but if it is allowed,
then that would be a good reason "adding a member function" isn't trivial.
I'm not aware of any vendors that make `exception_ptr` *anything but* a
plain old class named `exception_ptr`. I'd wholeheartedly support a paper
to just define it that way in the Standard, if anyone's interested in
bringing one.


> 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.
> On Fri, Mar 1, 2024 at 4:41 PM, Arthur O'Dwyer wrote:
> > - 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.
>
> 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:
>

The plugin should throw an exception derived from std::exception. Then you
can catch it:
    } catch (const std::exception& pluginEx) {
and just ask it for all its stuff:
        puts(pluginEx.what()); // prints something like "FieryShadow:
access out of bounds" or whatever
        const auto& ti = typeid(pluginEx); // gives you the type_info for
FieryShadowError or whatever its dynamic type is

If the plugin is throwing random stuff that's not derived from
std::exception, then
- The plugin has a bug; get them to fix it.
- All bets are off, anyway. They might be throwing `int`, or
`std::optional<std::string>`, or `std::nullptr_t` — you have no idea.

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


You can get a raw pointer to the first byte of the most-derived object via
`dynamic_cast<void*>(&pluginEx)`.
Unfortunately I don't think you can get the *size* of the most-derived
object in any way; all you know for sure is that it's no smaller than
sizeof(pluginEx).

–Arthur