Date: Mon, 4 Mar 2024 00:06:56 +0100
_set_se_translator is a way to customize C exceptions and optionally automatically convert them to C++ exceptions per thread:
https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/set-se-translator?view=msvc-170
The question is, whether "Microsoft could do it" and change the default for C structured exceptions under C++: Existing programs and libraries possibly rely on the current behaviour.
It is a runtime setting per thread and not a setting per translation unit. So changing the default for a new C++ standard version would possibly lead to incompatibilities, when mixing standard version of TUs or incorporating static or dynamic libraries.
The other question is, whether changing the behaviour of C structured exceptions is necessary at all for the proposal.
But generally, for your proposal, you want to be able to access RTTI type information for caught exceptions.
You give three usage examples:
a) Parsing the implementation defined name to search for keywords within the string
b) Comparing with a list of type_infos
c) Creating debug output, if type_info is expanded in the future
a) is quite weak, you are looking for a substring within a mangled name, which is implementation-defined
b) IMHO is your strongest example.
You want to test for a dynamic list of exception types (with RTTI information).
P2927 (try_cast) and C++ catch need static types, so they only would help indirectly (e.g. by calling a callback function that try_casts through the list)
c) needs future type_id improvements, before it is usable
BTW please have a look at the godbolt links within p2927r1:
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p2927r1.html
E.g. https://godbolt.org/z/ErePMf66h
It is much more similar to what you are doing than what you stated.
-----Ursprüngliche Nachricht-----
Von:Frederick Virchanza Gotham via Std-Proposals <std-proposals_at_[hidden]>
Gesendet:So 03.03.2024 23:15
Betreff:Re: [std-proposals] std::typeid_except ( Paper Attached )
An:std-proposals <std-proposals_at_[hidden]>;
CC:Frederick Virchanza Gotham <cauldwell.thomas_at_[hidden]>;
On Sun, Mar 3, 2024 at 6:04 PM Tom Honermann wrote:
>
> Microsoft's C++ exception handling implementation is built on top of SEH
> exceptions. When compiled in cl /EHa mode, a catch(...) handler will be
> entered for SEH exceptions. In this case, there isn't really an
> associated C++ type for the exception. See
> https://learn.microsoft.com/en-us/cpp/cpp/exception-handling-differences?view=msvc-170.
> This is obviously implementation-defined territory, but it might be
> worth exploring some. I don't know what std::current_exception() returns
> when called in these cases and it isn't convenient for me to check right
> now. I'd be curious to learn what is done though.
If you scroll down to the end of that webpage you linked us to, take a
look at the last block of code. I've modified it so that SEH_Exception
derives from std::exception as follows:
// Compile with Microsoft C++ compiler with option /EHa
#include <cstdio> // sprintf
#include <exception> // exception
#include <iostream> // cout, endl
#include <eh.h> // _set_se_translator, _EXCEPTION_POINTERS
class SEH_Exception : public std::exception {
private:
unsigned const var_number;
mutable char var_what[14u + 1u];
public:
SEH_Exception(unsigned const arg) noexcept : var_number(arg) {}
unsigned number(void) noexcept { return var_number; }
char const *what(void) const noexcept override
{
std::sprintf(this->var_what, "SEH 0x%08x", this->var_number );
return this->var_what;
}
};
void DivideByZero(void)
{
int x, y = 0;
x = 5 / y;
}
void trans_func(unsigned const u, _EXCEPTION_POINTERS*)
{
throw SEH_Exception(u);
}
int main(void)
{
_set_se_translator( trans_func );
try
{
DivideByZero();
}
catch(std::exception const &e)
{
std::cout << e.what() << std::endl;
}
}
This is one way that Microsoft could do it. Alternatively they could
throw a simple 'unsigned int', or an SEH_Exception class that doesn't
derive from std::exception.
--
Std-Proposals mailing list
Std-Proposals_at_[hidden]
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
Received on 2024-03-03 23:06:58