Unlike the concerns asked in that other questions, the answer to this question can be answered entirely by means of the Standard. Here are the rules
A handler is a match for an exception object of type E if
- The handler is of type cv T or cv T& and E and T are the same type (ignoring the top-level cv-qualifiers), or
- the handler is of type cv T or cv T& and T is an unambiguous public base class of E, or
- the handler is of type cv1 T* cv2 and E is a pointer type that can be converted to the type of the handler by either or both of
- a standard pointer conversion (4.10) not involving conversions to pointers to private or protected or ambiguous classes
- a qualification conversion
[Note: a throw-expression which is an integral constant expression of integer type that evaluates to zero
does not match a handler of pointer type; that is, the null pointer constant conversions (4.10, 4.11) do not
apply. ]
As i'm not quite sure about your level of understanding of the Standard, i will leave this unexplained, and answer as you ask.
With regard to whether it uses RTTI or not - well, the type of the exception object being thrown is the static type of the expression you hand over to the throw
statement (some time ago, i had fun figuring this out in GCC). So it does not need to do runtime type identification. So it happens, with g++
, that at the side where the throw
appears, it hands over a std::type_info
object representing the type of the exception object, the object itself and a destructor function.
It's then thrown and frames are searched for a matching handler. Using information found in big tables (located in a section called .eh_frame
), and using the return address, it looks what function is responsible for the next handling. The function will have a personality routine installed that figures out whether it can handle the exception or not. This whole procedure is described (and in more detail, of course) in the Itanium C++ ABI (implemented by G++) linked by @PaV.
So, to conclude
myexceptiontype e
and
const myexceptiontype *e
Do not handle the same type, of course.