Condition Handling END; DROP TABLE test.t; -- occurs within outer block END; mysql>  CALL p3(); +------------------------------------+ | msg | +------------------------------------+ | SQLEXCEPTION handler was activated | +------------------------------------+ CREATE PROCEDURE p4() BEGIN -- outer block BEGIN -- inner block DECLARE CONTINUE HANDLER FOR SQLEXCEPTION SELECT ’SQLEXCEPTION handler was activated’ AS msg; DECLARE CONTINUE HANDLER FOR SQLSTATE ’42S02’ SELECT ’SQLSTATE handler was activated’ AS msg; END; DROP TABLE test.t; -- occurs within outer block END; mysql>  CALL p4(); ERROR 1051 (42S02): Unknown table ’test.t’ Only the  SQLEXCEPTION  handler applies because the other one is not in scope for the condition raised by the  DROP TABLE : In this procedure, both handlers are declared in a block inner to the scope of the  DROP TABLE  statement: Neither handler applies because they are not in scope for the  DROP TABLE . The condition raised by the statement goes unhandled and terminates the procedure with an error: SQL statements produce diagnostic information that populates the diagnostics area. Standard SQL has a diagnostics area stack, containing a diagnostics area for each nested execution context. Standard SQL also supports  GET STACKED DIAGNOSTICS  syntax for referring to the second diagnostics area during condition handler execution. The following discussion describes the structure of the diagnostics area in MySQL, the information items recognized by MySQL, how statements clear and set the diagnostics area, and how diagnostics areas are pushed to and popped from the stack. 13.6.7.7 The MySQL Diagnostics Area •Diagnostics Area Structure •Diagnostics Area Information Items •How the Diagnostics Area is Cleared and Populated •How the Diagnostics Area Stack Works •Diagnostics Area-Related System Variables •Statement information, such as the number of conditions that occurred or the affected-rows count. The diagnostics area contains two kinds of information: Diagnostics Area Structure 2829