Brendon Costa <[EMAIL PROTECTED]> writes:
> The nodes that have me a little confused are:
>
> TRY_CATCH_EXPR
> TRY_FINALLY_EXPR
> MUST_NOT_THROW_EXPR
> EH_FILTER_EXPR
Yes, those are a bit mysterious.
> TRY_CATCH_EXPR/TRY_FINALLY_EXPR
> When code generated from these nodes encounter an exception while
> processing code from operand 0 is there an implicit rethrow of that
> exception at the end of the block of code given by operand 1 or does it
> "sink" the exception and only rethrow it if the user specifically
> requests it (In C++ anyway)?
If operand 0 throws an exception, there is an implicit rethrow after
executing operand 1. (Of course, operand 1 can prevent that rethrow
by doing its own throw, or by calling a function which does not
return, etc.).
> In what situations are these nodes generated?
TRY_CATCH_EXPR is generated for C++
try { ... } catch (...) { }
TRY_FINALLY_EXPR is generated for
class C { ~C(); }; ... { C c; ... }
to ensure that C's destructor is run.
And of course they can be generated for other languages as well.
> MUST_NOT_THROW_EXPR
> What sort of code produces one of these nodes? They do not seem to be
> used for the throw() specifiers for a function (At least in C++) as i
> would have expected.
MUST_NOT_THROW_EXPR is a C++ specific code. It is used for a few
places which must not throw, like the copy constructor of a catch
parameter. It is eliminated during gimplification. throw() is
handled via EH_SPEC_BLOCK, which is another C++ specific code
eliminated during gimplification.
> EH_FILTER_EXPR
> In what situations are these nodes generated?
EH_FILTER_EXPR is generated when EH_SPEC_BLOCK and MUST_NOT_THROW_EXPR
are gimplified.
> I assume that the code
> that these filters applies to is external to the node and if an
> exception occurs in this external code that does not match any of the
> types in the EH_FILTER_TYPES list (Do they have to be exact matches/how
> is type matching done here) then it calls the EH_FILTER_FAILURE which
> could be for example a call to terminate()?
EH_FILTER_EXPR will be operand 2 of a TRY_CATCH_EXPR. When the body
(operand 1) of the TRY_CATCH_EXPR throws an exception, then if operand
2 is EH_FILTER_EXPR, the exception is matched against EH_FILTER_TYPES.
If the exception does not match, then EH_FILTER_FAILURE is called.
EH_FILTER_FAILURE is normally a call to terminate() or unexpected().
> How does the EH_FILTER_MUST_NOT_THROW() macro work?
It generates an exception region such that if an exception is seen
there, terminate is called. (At least, I think that is how it works.)
> If it returns true
> then the filter allows NO exceptions and if false then allows only
> exceptions of type that are in this list?
Yes.
> Is it possible for the
> EH_FILTER_TYPES list to be empty and EH_FILTER_MUST_NOT_THROW() to
> return false?
Perhaps. The two cases are essentially equivalent.
Ian
