On Mon, Mar 4, 2024 at 10:34 AM Sebastian Wittmeier wrote:
>
> I think this is the right behaviour:
>
> Regardless whether the user uses no flag, /EHsc, /EHs or /EHa; and whether
> the user registers a _set_se_translator() wrapper, your typeid_except (I also
> prefer `exception_typeid`; `_except` sounds more like except vs. noexcept)
> should take, what it gets.
>
> Installing by default a new _set_se_translator( trans_func ); wrapper with
> changed defaults for C structured exceptions would possibly break things
> and would unnecessarily widen the scope of your paper.
>
> If you or Microsoft see the necessity, they would probably use a new flag,
> e.g. /EHt for throw exception with RTTI type information by default.
>
> Probably they won't, as currently they do not throw a C++ exception automatically,
> but offer to register the _set_se_translator(); wrapper. And then the user can
> choose, which C++ exception is thrown.


Okay I've amended the paper as follows:

    * I've removed the default argument (which was 'current_exception()')
    * I've corrected the sample code which had 'sizeof_except' where I
had intended 'sizeof_type_info'.
    * Under the heading 'Design considerations', I talk specifically
about Microsoft's SEH exceptions

You can see the latest version of the paper here:

    http://www.virjacode.com/papers/typeid_except.htm

and also it's attached to this email.