MySQL Internals Manual  /  ...  /  Exception Handlers Exception Handlers


As of MySQL 5.1, which is the code base described by this documentation, the statements SIGNAL, RESIGNAL and GET DIAGNOSTICS are not supported. Implementing these features will have some impact on the material described here, so changes in later versions are anticipated.

When the code enters a block of logic guarded by an SQL exception handler, the state or the runtime context in the interpreter changes, to represent this fact. The state change is not apparent immediately, it will only become apparent if an exception is raised. The internal runtime state of the engine also changes when the code leaves a block that contains an exception handler.

How exception handlers work during runtime is the subject of another section (see Section 16.7.4, “Exception Handling”). What is described here is the state maintained internally, to represent which HANDLER is currently active, and what CONDITION is protected against.

The SQL precedence rules for HANDLER dictates that the last installed (inner most) handler is always considered first, so the natural structure to represent what handler is active is a stack, implemented by sp_rcontext::m_handler and sp_rcontext::m_hcount.

In addition, some extra information is required for CONTINUE handlers: the address in the code, or instruction pointer in the sp_instr array, of where to resume execution when the handler returns. This data is maintained in sp_rcontext::m_hstack and sp_rcontext::m_hsp, which again is a stack because exception handlers can be nested (exceptions can be raised and trapped during the execution of the body of an exception handler, too).

User Comments
Sign Up Login You must be logged in to post a comment.