Brendon Costa <[EMAIL PROTECTED]> writes:
> >>TRY_CATCH_EXPR/TRY_FINALLY_EXPR
> >>
> >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.).
> > 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.
> >
>
> For the C++ code shown above try { ... } catch(...) {}
> From memory I get a TRY_BLOCK node and not a TRY_CATCH_EXPR.
TRY_BLOCK is a C++ language specific code. It is converted to
TRY_CATCH_EXPR during gimplification. See genericize_try_block.
> Also is the implicit rethrow just for the TRY_FINALLY_EXPR and not for
> the TRY_CATCH_EXPR or is it for both of them?
It's for both of them. If the body of a TRY_FINALLY_EXPR throws an
exception, then the finally clause, operand 1, will be executed. If
the finally clause completes normally, then the exception will be
rethrown. To be clear, if the body of a TRY_FINALLY_EXPR completes
normally, or executes a return statement, then the finally clause
won't throw an exception, it will continue with the next statement or
do a return. In other words, the finally clause is run, and then
whatever else was going to happen happens. And, to be clear, if the
finally clause throws an exception, then that is the exception that
will be thrown, and the original exception will not be rethrown and
will, in fact, be ignored.
Ian
