How to obtain the type of the exception in 'catch (...)'?

[Martin]

Hi.

I need to identify the type of the exception in the universal handler
(catch (...)) for debugging purposes. Point is that I write a testing
console application, which must call some functions from a DLL. One of
these functions throws an exception, and since my small application
knows nothing about the exception type system of that DLL application,
the generated exception always caught in 'catch (...)'. I've made some
small investigations: it turned out (as I could understand...), that
MSVC recognizes the right handler by the name of the exception type.
E.g., I've created a DLL, exporting function 'Func', throwing an
object of type 'A':

*** DLL's implementation part ***

class A
{
public:
int m_a, m_b;
double m_c;
};

__declspec(dllexport) int Func()
{
throw A();
}

*************************************

And here's a small .exe, which will call 'Func' from DLL:

*** EXE's implementation part ***

class A
{
};

int _tmain(int argc, _TCHAR* argv[])
{
using namespace std;

try
{
Func();
}
catch (const A&)
{
cerr << "Caught 'A'\n";
}
catch (...)
{
cerr << "Unknown exception...\n";
}

return 0;
}

**********************************************************

It's surprising, that the program writes out "Caught 'A'", though
conceptually the type of the thrown object is not the same... And this
makes me think, that runtime somehow knows the name of the thrown
type, and moreover, it identifies the needed handler by the NAME of
the type of exception object. So, how to obtain that name in catch
(...)?

Thanks in advance
Martin

 

[Andre Kostur]

Hi.

I need to identify the type of the exception in the universal handler
(catch (...)) for debugging purposes. Point is that I write a testing
console application, which must call some functions from a DLL. One of
these functions throws an exception, and since my small application
knows nothing about the exception type system of that DLL application,
the generated exception always caught in 'catch (...)'. I've made some
small investigations: it turned out (as I could understand...), that
MSVC recognizes the right handler by the name of the exception type.
E.g., I've created a DLL, exporting function 'Func', throwing an
object of type 'A':

[snip]

Two items:
1) DLLs are off-topic in comp.lang.c++ (please ask over in a Microsoft
newsgroup)
2) You cannot determine the type of a thrown exeception object from within
a catch(...) clause.

 

[James Kanze]

I need to identify the type of the exception in the universal handler
(catch (...)) for debugging purposes.

You can't, at present. I believe, however, that support for
this is being added to the standard, and will be present in the
next version of the standard.

Point is that I write a testing
console application, which must call some functions from a DLL. One of
these functions throws an exception, and since my small application
knows nothing about the exception type system of that DLL application,
the generated exception always caught in 'catch (...)'. I've made some
small investigations: it turned out (as I could understand...), that
MSVC recognizes the right handler by the name of the exception type.
E.g., I've created a DLL, exporting function 'Func', throwing an
object of type 'A':

The fact that it's a DLL doesn't make any difference, formally.
(In practice, it might, depending on the implementation. But
there, you're in an implementation dependant situation, and
you'd have to ask in a Windows group.)

*** DLL's implementation part ***

class A
{
public:
int m_a, m_b;
double m_c;
};

__declspec(dllexport) int Func()
{
throw A();
}

And here's a small .exe, which will call 'Func' from DLL:

*** EXE's implementation part ***

class A
{
};

If you link these two modules together, dynamically or
otherwise, you have undefined behavior, at least according to
the rules of C++. You've violated the one definition rule.

I think that Windows does allow this, as an extention; that the
type in the DLL remains limited to the DLL. But if that's the
case, then you have a different problem: you've lied to the
compiler, because you've said that the type won't escape from
the DLL, and it does, in the form of an exception. Again,
you're dealing with a Windows extension, and will have to ask in
a Windows group, but if I were implementing this, the only way
you could legally refer to an object of the non-exported type
outside of the DLL would be through a void*.

int _tmain(int argc, _TCHAR* argv[])
{
using namespace std;

try
{
Func();
}
catch (const A&)
{
cerr << "Caught 'A'\n";
}
catch (...)
{
cerr << "Unknown exception...\n";
}
return 0;
}

It's surprising, that the program writes out "Caught 'A'", though
conceptually the type of the thrown object is not the same...

Since you have undefined behavior, nothing is surprising. In
fact, this behavior doesn't surprise me from a practical point
of view either; C++ uses name equivalence: a type named A is (or
had better be) the same type everywhere.

And this makes me think, that runtime somehow knows the name
of the thrown type, and moreover, it identifies the needed
handler by the NAME of the type of exception object.

The runtime identifies the object by its type. In C++, however,
two types are the same type if and only if they have the same
type name. (Note that typedef doesn't change either the type,
nor its name; it only allows you to refer to it by a different
name.)

So, how
to obtain that name in catch (...)?

For the moment, you can't.

 

[Pete Becker]

You can't, at present. I believe, however, that support for
this is being added to the standard, and will be present in the
next version of the standard.

The main addition to exceptions (voted into the WD two weeks ago in
Toronto) is being able to "save" an exception object via a handle and
rethrow it later. An earlier version of that paper had extensions to
type_info, but those were removed. So there's currently no proposal for
getting the type of an exception object.