Previous: Cleanups, Up: Statements
10.2.4.8 Exception Handling
Other exception handling constructs are represented using
TRY_CATCH_EXPR
. TRY_CATCH_EXPR
has two operands. The
first operand is a sequence of statements to execute. If executing
these statements does not throw an exception, then the second operand
is ignored. Otherwise, if an exception is thrown, then the second
operand of the TRY_CATCH_EXPR
is checked. The second operand
may have the following forms:
- A sequence of statements to execute. When an exception occurs, these statements are executed, and then the exception is rethrown.
- A sequence of
CATCH_EXPR
expressions. EachCATCH_EXPR
has a list of applicable exception types and handler code. If the thrown exception matches one of the caught types, the associated handler code is executed. If the handler code falls off the bottom, execution continues after the originalTRY_CATCH_EXPR
. - An
EH_FILTER_EXPR
expression. This has a list of permitted exception types, and code to handle a match failure. If the thrown exception does not match one of the allowed types, the associated match failure code is executed. If the thrown exception does match, it continues unwinding the stack looking for the next handler.
Currently throwing an exception is not directly represented in GIMPLE, since it is implemented by calling a function. At some point in the future we will want to add some way to express that the call will throw an exception of a known type.
Just before running the optimizers, the compiler lowers the high-level
EH constructs above into a set of `goto's, magic labels, and EH
regions. Continuing to unwind at the end of a cleanup is represented
with a RESX_EXPR
.