On 3/4/24 8:15 AM, Frederick Virchanza Gotham via Std-Proposals wrote:
> 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

Since we can't dictate the behavior for SEH handling, "typeid_except(p)
shall return typeid(void)" seems a little too prescriptive. You might
water this down to a recommendation.

Did you happen to explore what happens with current_exception() for the
pthread cancellation case that Thiago noted? I would be curious to know
what happens there too.

Tom.

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